Python 虚拟环境避坑实录：venv、pip 与依赖锁定的正确姿势

刚学 Python 的同学几乎都会遇到同一个经典场面：在 A 项目里装了 requests 2.31，一切正常；转头去跑 B 项目，报错说 requests 版本不对。把 B 项目的依赖升级之后，A 项目又挂了。这种“拆东墙补西墙”的循环，根源都是把包装进了全局 Python 环境里。

正确的做法是：一个项目，一个虚拟环境。Python 3.3 之后标准库自带的 venv 就够用，不用再装第三方工具。进入项目目录后执行 python -m venv .venv，会在当前目录下生成一个独立的解释器副本和 site-packages。之后所有 pip install 都只影响这个目录，系统 Python 干干净净。

激活环境分两种情况。Linux / macOS 下是 source .venv/bin/activate，Windows 下是 .venv\Scripts\activate。激活成功后命令行前面会出现 (.venv) 前缀，这是最直观的确认方式。退出用 deactivate。很多人第一次用 venv 的坑就出在这里：忘了激活，直接 pip install，又装回全局了。建议把“先激活、再安装”写成肌肉记忆，或者在项目 README 里写明步骤。

第二个坑是依赖记录。只写“我用了 requests”是不够的，别人按你的说明 pip install requests，装到的是最新版，和你当初开发的版本可能已经不兼容。标准做法是 pip freeze > requirements.txt，把精确版本号锁死。但 pip freeze 有个副作用：它会导出环境里所有的包，包括你随手装来试用的。这会让 requirements.txt 变得臃肿。更干净的做法是手动维护 requirements.txt，只写项目直接依赖的包和版本范围，比如 requests>=2.28,<3；部署时再用 pip install -r requirements.txt 安装。

第三个坑和操作系统有关。有些包带 C 扩展，在 Linux 上 pip 装的是预编译 wheel，一切顺利；换到某些精简镜像里缺编译工具链就会报错。这时候别急着 apt 装 gcc，先看看是不是 Python 版本太新、对应 wheel 还没发布。生产环境建议用官方 python:3.x-slim 镜像，配合 requirements.txt 做多阶段构建，依赖装一次、镜像里只留运行产物。

总结一下这套流程：python -m venv .venv 建环境，激活后安装依赖，手动维护一份精简的 requirements.txt，部署时从锁文件重建环境。四个步骤，刚开始觉得麻烦，项目一多就会发现，这是省掉无数“在我机器上明明是好的”争吵的最便宜方案。虚拟环境不是可选项，是 Python 工程化的起点。