Python 虚拟环境入门：从 venv 创建到依赖管理的完整实践

为什么每个 Python 项目都值得一个独立的虚拟环境？很多新手一开始都在系统 Python 里直接 pip install，项目一多，依赖版本很快打架：A 项目要 requests 2.28，B 项目要 2.32；一个库升级，另一个项目突然跑不起来。虚拟环境就是给每个项目划一块干净的试验田，解释器和第三方包互不干扰，出了问题删掉重建也不心疼。

一、什么是虚拟环境

虚拟环境是一份独立的 Python 运行目录，里面有自己的解释器副本、pip 和 site-packages。激活后，命令行里的 python 和 pip 都会指向它，而不是系统全局环境。项目 A 装 Django 4，项目 B 装 Django 5，可以并存。更重要的是，它让“在我机器上能跑”变成可复现的依赖清单，而不是口头经验。

二、用 venv 创建并激活

Python 3.3 起自带 venv，不需要额外安装。在项目根目录执行：

python3 -m venv .venv
source .venv/bin/activate

Windows PowerShell 下激活命令是 .venv\Scripts\Activate.ps1。成功后命令行前面会出现 (.venv) 前缀，这就是最直观的确认方式。退出用 deactivate。建议把目录命名为 .venv，并在 .gitignore 里加上它，虚拟环境本身不应该进版本库。

三、依赖管理要养成三个习惯

第一，安装后立刻固化版本：pip freeze > requirements.txt。第二，新环境先装依赖再跑代码：pip install -r requirements.txt，这样同事或服务器能一键复现。第三，区分运行依赖和开发依赖，测试、格式化工具可以单独放进 requirements-dev.txt，避免生产环境装一堆用不上的包。版本约束不必全部钉死，但关键库建议写明大版本范围，升级时心里有数。

四、新手最容易踩的四个坑

一是激活了环境，却用绝对路径调用了系统 Python，检查办法是先跑 which python 或 where python。二是把 .venv 提交到了 Git，仓库瞬间变大，删掉后重新创建即可。三是直接用 sudo pip install 往系统里装包，既污染环境又可能破坏系统工具，虚拟环境里完全不需要 sudo。四是多个项目共用一个环境，图省事最后还是回到版本冲突的起点，项目一换就新建环境，成本其实很低。

五、venv、virtualenv 和 conda 怎么选

只做纯 Python 开发，标准库 venv 已经够用；需要支持旧版本或更快的创建速度，可以用 virtualenv；涉及科学计算、非 Python 依赖或跨语言环境，conda 的包管理面更广。但工具不是越多越好，一个团队统一一种约定，比每个人用不同工具更重要。进阶之后可以再看 pyproject.toml、pip-tools 或 uv，它们解决的是依赖解析和锁定，比手动维护 requirements 更稳。

六、排障清单

激活后前缀没出现，先确认 shell 类型和激活脚本是否对应；pip 装不上包，先看网络和镜像源，再看 Python 版本是否被库放弃支持；依赖冲突时不要一个个试运气，用 pip check 看冲突关系，必要时新建干净环境重新安装。把“删掉重建”当成正常操作，而不是最后手段，心态会轻松很多。

虚拟环境不是炫技，而是职业习惯：隔离、固化、可复现。项目开始的第一条命令先建环境，结束时留下一份 requirements，这两步做扎实，后续的部署、协作和排障都会顺很多。