为什么以及如何使用虚拟环境？

Question

为什么以及如何使用虚拟环境？

Accepted Answer

**虚拟环境**是一个隔离的 Python 环境，拥有自己安装的包，与系统 Python 和其他项目分离。它解决了**依赖冲突**的问题——不同的项目可以使用相同包的不同版本（甚至不兼容的版本）。

## 它解决的问题

```text
Project A needs Django 3.2
Project B needs Django 4.2
→ Installing globally, they CONFLICT — you can't have both versions system-wide.
Virtual environments give each project its OWN isolated set of packages.
```

不进行隔离，全局安装包会导致项目之间的版本冲突，并可能破坏依赖于特定版本的系统工具。

## 创建并使用虚拟环境（内置 venv）

```bash
# 1. create a virtual environment (a folder named .venv)
python -m venv .venv

# 2. ACTIVATE it (shell-specific)
source .venv/bin/activate      # macOS/Linux
.venv\Scripts\activate         # Windows

# 3. now pip installs go INTO this env, isolated from the system
pip install django requests

# 4. when done
deactivate
```

激活后，`python` 和 `pip` 指向环境隔离的副本——包仅安装在那里，而不是系统范围内。

## 捕获和复现依赖

```bash
pip freeze > requirements.txt       # record exact installed versions
pip install -r requirements.txt     # recreate the env elsewhere (teammate, CI, prod)
```

`requirements.txt` 使环境**可复现**——任何人都可以重新创建完全相同的依赖，防止"在我的机器上可以工作"的问题。

## 现代工具

```text
venv + pip      → built-in, standard, widely used
poetry          → dependency management + lockfile + packaging (popular)
pipenv          → combines pip + venv with a lockfile
uv / pdm        → newer, faster tools
conda           → common in data science (manages Python versions + non-Python deps too)
```

更新的工具（poetry、uv）添加了 lockfiles 和更好的依赖解析，但核心概念——隔离的项目环境——是相同的。

## 始终从版本控制中排除环境

```text
# .gitignore
.venv/        ← don't commit the environment; commit requirements.txt/lockfile instead
```

## 为什么这很重要

虚拟环境是任何 Python 项目的必要且标准的实践——它们防止项目之间以及项目与系统 Python 之间的依赖冲突，并且（使用 `requirements.txt`/lockfiles）使环境在机器、团队成员、CI 和生产环境中可复现。

跳过它们会导致版本冲突、破坏的系统工具和不可复现的设置。

了解如何创建、激活和捕获依赖——以及现代工具景观（poetry、uv）——对专业 Python 开发是基础，也是任何真实项目中的基本期望。