Python 虚拟环境 venv 入门：给每个项目一间干净的房间

刚开始学 Python 时，很多人都会把所有包一股脑装进系统全局环境：今天装 requests，明天装 Django，后天又装一个要求旧版本依赖的工具。没过多久，版本冲突、报错、“在我电脑上明明能跑”就接踵而至。其实 Python 自带了一个轻量解法：venv 虚拟环境。它相当于给每个项目单独准备一间干净的“房间”，互不干扰。

一、什么是虚拟环境

虚拟环境就是一份独立的 Python 解释器副本，加一套独立的第三方包目录。进入环境后，pip 安装的包只会落到这个环境里；退出环境后，全局 Python 完全不受影响。不同项目的依赖版本可以并存：一边跑要求 Django 4 的老项目，一边学 Django 5 的新教程，互不打架。

从 Python 3.3 开始，venv 就是标准库的一部分，不需要额外安装，这也是它最适合新手的地方：零成本、够用、不折腾。

二、创建你的第一个虚拟环境

在项目目录下执行：

python -m venv .venv

这条命令会在当前目录生成 .venv 文件夹，里面包含解释器副本和 pip。命名习惯上，社区最常用 .venv，开头的点表示“隐藏”，提醒自己这不是源码。

三、激活与退出

创建只是第一步，关键是“激活”：激活后，终端的 python 和 pip 都会指向这个环境。

Windows PowerShell：

.\.venv\Scripts\Activate.ps1

macOS / Linux：

source .venv/bin/activate

成功后，命令行前面会出现 (.venv) 提示符，这就是“已进入房间”的标志。做完工作，用一句 deactivate 就能退出，提示符消失，回到全局环境。

新手最常见的坑，就是在没有激活的情况下 pip install，结果包还是装到了全局。每次开工前，先看一眼提示符，养成习惯能少走很多弯路。

四、依赖管理：让环境可复制

虚拟环境的真正价值，在团队协作时最明显。装好依赖后，用一条命令把依赖清单写出来：

pip install requests
pip freeze > requirements.txt

requirements.txt 记录了每个包和精确版本号。别人拿到项目后，只要创建虚拟环境并执行：

pip install -r requirements.txt

就能还原出几乎一样的环境。“在我电脑上能跑”的问题，一大半靠这一招解决。

五、三个容易踩的坑

第一，别把 .venv 传到代码仓库。它体积大、依赖操作系统，别人用不上。在 .gitignore 里加上一行 .venv/ 就行。

第二，一个环境不要跨项目复用。图省事把所有项目的包都塞进同一个虚拟环境，等于回到了“一个大房间”的老路。

第三，升级 Python 大版本后，旧虚拟环境不一定能直接用。稳妥的做法是新建环境、重新安装依赖，让 requirements.txt 发挥作用。

六、可以慢慢升级的习惯

等你熟悉了这套流程，还可以继续升级工具链：用 pip-tools 锁定依赖，用 uv 或 Poetry 更快地管理环境，用 Docker 把环境连同系统依赖一起打包。这些都是在 venv 思想上的延伸：隔离、可复制、干净。

虚拟环境可能是 Python 新手最值得先学会的习惯之一。先用 .venv 给每个项目一间干净的房间，后面的学习之路会顺畅很多。今天就可以试试：选一个正在写的项目，创建虚拟环境，重新安装依赖，感受一下从“全局一锅粥”到“各归其位”的变化。