📚 课程目录第4章 Python环境隔离

4. Python 环境隔离：virtualenv 与 pipenv 实战

Python 的环境隔离，说白了就是给你的每个项目建一个“沙箱”。

我刚开始写 Python 时，所有依赖都装全局。结果有一次要同时维护 Django 1.11 和 3.2 的项目，那叫一个酸爽——不是版本冲突，就是装完一个项目另一个直接崩掉。从那以后，我学乖了，每个项目必须隔离。

核心观点： 环境隔离不是可选项，而是 Python 项目的必备基础设施。否则项目一多，依赖地狱就来了。

4.1 为什么需要虚拟环境？

先看一个真实的场景：你的项目 A 用 requests==2.25.0，项目 B 用 requests==2.31.0。如果全装在一个全局环境里，后者会覆盖前者。升级后项目 A 的某些旧 API 调用直接出错。

虚拟环境解决的就是这个问题。每个环境有自己的 site-packages 目录，互不干扰。你甚至可以为同一个项目创建多个环境，分别对应开发、测试和生产。

对比项	全局环境	虚拟环境
依赖隔离	❌ 所有项目共享	✅ 项目级隔离
版本管理	只能装一个版本	可同时装不同版本
卸载清理	不敢乱删	直接删目录
团队协作	难以复现环境	锁定文件搞起

4.2 第一款工具：virtualenv

virtualenv 是 Python 环境隔离的元老，也是很多高级工具（比如 pipenv、poetry）的底层依赖。

安装

Python 3.3+ 自带 venv 模块，它和 virtualenv 类似但功能少一些。我个人习惯用 virtualenv，因为它更稳、兼容性更好。

# 安装 virtualenv
pip install virtualenv

# 验证安装
virtualenv --version

创建虚拟环境

命令很简单，指定一个目录名即可。我建议用 .venv 或 venv 作为名字，团队一看就明白。

# 创建环境（默认使用系统 Python）
virtualenv .venv

# 指定 Python 版本（我在项目里常用这个）
virtualenv -p python3.10 .venv

创建后，.venv 目录下会出现 bin（Linux/macOS）或 Scripts（Windows），里面是 Python 解释器和 pip 的副本。

小技巧： 把 .venv/ 加进 .gitignore，别提交到仓库。环境是个人配置，锁定文件才是团队的。

激活与停用

激活后，终端提示符前面会显示环境名，你可以清楚地知道自己现在在哪个环境里。

# Linux/macOS
source .venv/bin/activate

# Windows (PowerShell)
.venv\Scripts\Activate.ps1

# Windows (CMD)
.venv\Scripts\activate.bat

# 停用
deactivate

我记得有一次急着上线，在服务器上跑项目，忘了激活环境，结果 pip install 全装到全局了。后来排查半天才发现是环境没激活。嗯，这个坑我替你们踩过了。

依赖锁定与导出

# 激活环境后安装依赖
pip install requests flask

# 导出依赖
pip freeze > requirements.txt

requirements.txt 就是你的依赖清单。团队其他人拿到它后，直接 pip install -r requirements.txt 就能复现环境。

注意： pip freeze 会输出所有已安装的包，包括子依赖。这会导致锁定文件冗余。建议只写顶层依赖，子依赖交给 pip 自己解析。不过在实际项目中，全锁定也能接受，至少保证可复现。

4.3 第二款工具：pipenv

pipenv 是 virtualenv + pip 的升级版，还引入了 Pipfile 和 Pipfile.lock。我个人觉得它最大的好处是自动管理虚拟环境和依赖关系，不用手动激活和停用。

安装

# 使用 pip 安装
pip install pipenv

# 验证
pipenv --version

如果你用 Homebrew（macOS），也可以 brew install pipenv，不过我更喜欢 pip 版本，版本更可控。

创建虚拟环境

进入项目目录，执行 pipenv install。如果目录里没有 Pipfile，它会自动创建。

# 创建环境并安装依赖（如果没有 Pipfile，会生成一个）
pipenv install

# 指定 Python 版本（很实用）
pipenv --python 3.10

# 安装特定包
pipenv install requests flask

pipenv 会自动选择合适的 Python 版本创建虚拟环境。它会把环境放在一个统一目录下（比如 ~/.local/share/virtualenvs/），而不是项目目录里。

对比： virtualenv 的环境在项目目录里，pipenv 在统一目录。前者的好处是“所见即所得”，后者则更整洁，适合多个项目共享同一个基础环境路径。

激活与执行命令

pipenv 不推荐手动激活。你直接用 pipenv run 执行命令就行。

# 直接在环境中运行命令
pipenv run python app.py
pipenv run pytest

# 或者进入环境 shell
pipenv shell

pipenv shell 会启动一个子 shell，里面的 Python 和 pip 都是环境里的。退出时 exit 即可。

我曾经在一个 CI 脚本里用 pipenv run，结果发现它每次启动都要锁定解析，慢得要命。后来改成在 CI 里先 pipenv sync --dev 再 pipenv run python，速度快了三倍。你想想看，环境构建次数多了，这点优化很值得。

依赖锁定

# 更新锁定文件
pipenv lock

# 根据锁定文件安装（生产环境推荐）
pipenv sync

# 包括开发依赖
pipenv sync --dev

Pipfile.lock 记录了每个依赖的精确版本和哈希值，确保任何人在任何时候都能得到一模一样的环境。

两个工具的锁定文件对比：
virtualenv + requirements.txt： 手动生成，只记录版本号，不记录哈希。子依赖版本可能被动变化。
pipenv + Pipfile.lock： 自动生成，记录了哈希值和依赖树。安全性更高，但文件较大。

4.4 实战选择建议

说了这么多，到底该用哪个？我根据项目场景给你一个参考：

场景	推荐工具	理由
简单脚本、小工具	virtualenv	轻量、无额外依赖
Web 应用、团队项目	pipenv 或 poetry	锁定文件更可靠，依赖管理更自动
CI/CD 流水线	pipenv	支持 `pipenv sync` 快速复现
遗留项目已有 requirements.txt	virtualenv	不要强行迁移，划不来
新项目、追求现代化	pipenv 或 poetry	生态更完善，开发体验更好

4.5 一张图看懂流程

下面这张图展示了两种工具的完整使用流程。我用不同颜色区分了 virtualenv（蓝）和 pipenv（绿），方便你对比。

4.6 避坑指南

不要升级系统 Python 自带的 pip： 系统 Python 的 pip 被改了，可能会导致某些系统工具（比如 apt/yum）失效。在虚拟环境里随便升级没关系。
跨平台要注意： source .venv/bin/activate 在 Windows 上不可用。Windows 用户请用 .venv\Scripts\activate。pipenv 的 pipenv run 则跨平台一致。
Python 版本要明确： 我见过一个项目团队有 Python 3.8、3.9、3.10 的，结果有人在 3.8 下了依赖，提交的锁定文件里包含了 dataclasses（3.8 需要单独装，3.9+ 内置）。后面的人用 3.10 一跑就报错。所以一定要在项目文档里写清楚 Python 版本。

重要： 永远不要在虚拟环境之外运行 pip install。如果你发现安装的包出现在了全局 pip list 里，八成忘了激活环境。我早期犯过这个错，一个项目装了 50 多个全局包，后面想清理简直噩梦。

好了，Python 环境隔离这块就讲完了。记住核心思路：创建隔离环境 → 安装依赖 → 锁定版本 → 团队共享。不管是 virtualenv 还是 pipenv，只要做到这四步，你的项目依赖管理就不会乱。