VirtualEnv 21.4.0：Python 虚拟环境工具的持续精简

Python 项目多了，依赖冲突几乎是必然事件——A 项目要 Django 3.2，B 项目要 Django 4.1，全局 pip install 一装就打架。VirtualEnv 从根上解决这个问题：每个项目一套独立运行环境，互不干扰，部署时整包带走，服务器上不用再折腾依赖。

21.4.0 版本延续了近几个版本的"瘦身"路线，改动不大但方向明确。

这次改了什么

从 changelog 看，核心变更集中在两处：

• 修复 Mermaid flowchart 渲染问题（#3147）——VirtualEnv 的文档站点用 Mermaid 画流程图，之前某些图表渲染异常，这次做了修正。对日常使用没有直接影响，但如果你曾翻文档被乱掉的流程图困扰，现在正常了。
• refactor(create)：移除冗余代码并记录——创建虚拟环境的核心逻辑做了清理，删掉了重复路径，补充了内部注释。这意味着 virtualenv 创建环境的代码路径更干净，后续维护和排查问题会更顺畅。

总体来说，21.4.0 不是功能大版本，而是"扫灰补缝"的维护版。但结合 21.x 系列的整体趋势，能看到一个清晰方向：内部实现持续简化，对外接口保持稳定。

为什么虚拟环境仍然值得用

有人会问：Python 3.3 以后自带了 venv 模块，还需要 virtualenv 吗？答案是看场景：

最关键的区别是跨版本创建。当你机器上有 Python 3.8、3.9、3.11 共存，想为项目指定某个版本时，virtualenv --python=3.9 .venv 一行搞定，而 venv 只能用当前激活的解释器。

实操：从创建到部署

下面是一套可以直接复制运行的完整流程。

安装并创建环境

# 安装最新版 virtualenv
pip install --upgrade virtualenv

# 确认版本
virtualenv --version
# 输出: 21.4.0 (或更高)

# 为项目创建指定 Python 版本的虚拟环境
virtualenv --python=3.11 .venv

# 激活环境
source .venv/bin/activate   # Linux / macOS
# .venv\Scripts\activate    # Windows

# 验证环境隔离性
which python   # 应指向 .venv/bin/python
python --version  # 应输出你指定的版本
pip list       # 只有 pip/setuptools，没有全局包

安装项目依赖并锁定

# 在虚拟环境中安装依赖
pip install django==4.2 fastapi uvicorn

# 导出依赖清单——部署时直接用这个文件
pip freeze > requirements.txt

生成的 requirements.txt 内容类似：

django==4.2
fastapi==0.109.0
uvicorn==0.27.0

部署到生产服务器

# 在生产机器上，只需要两步
virtualenv --python=3.11 /opt/app/venv
source /opt/app/venv/activate
pip install -r requirements.txt

# 依赖完全一致，不需要在服务器上逐个调试

如果你追求更严格的可复现性，可以用 pip freeze 替换为 pip-compile（来自 pip-tools），它会锁定所有子依赖的精确版本。

用脚本一键重建环境

把以下内容保存为 setup_venv.sh，新成员 clone 项目后直接运行：

#!/usr/bin/env bash
set -euo pipefail

PYTHON_VERSION="${1:-3.11}"
VENV_DIR=".venv"

if [ ! -d "$VENV_DIR" ]; then
    virtualenv --python="$PYTHON_VERSION" "$VENV_DIR"
fi

source "$VENV_DIR/bin/activate"
pip install -r requirements.txt

echo "✅ 虚拟环境就绪，Python $(python --version)"

chmod +x setup_venv.sh
./setup_venv.sh 3.11

日常使用中的几个坑

不要在虚拟环境里再嵌套虚拟环境。 激活 .venv 后再跑 virtualenv 创建子环境，路径会混乱，which python 指向可能错位。需要不同版本就创建多个并列环境。

.venv 目录不要提交到 Git。 加进 .gitignore：

.venv/

只提交 requirements.txt 或 pyproject.toml，环境由每个开发者本地生成。

升级 virtualenv 本身时，已有环境不受影响。 已创建的 .venv 目录是独立的，升级工具只影响后续新建的环境。但如果你想让旧环境享受新版本的内部优化，最简单的办法是删掉重建：

rm -rf .venv
virtualenv --python=3.11 .venv
source .venv/bin/activate
pip install -r requirements.txt

选择建议

• 只用一个 Python 版本、需求简单 → python -m venv 够用，零额外安装。
• 多版本共存、需要指定版本创建 → virtualenv 是更顺手的选择。
• 团队项目、CI/CD 流水线 → virtualenv 的跨版本能力和速度优势更明显，配合 requirements.txt 脚本化重建即可。

21.4.0 没有引入破坏性变更，从任何 21.x 版本升级都是安全的：

pip install --upgrade virtualenv

一行命令，环境照旧运行，内部更干净。