Python 虚拟环境 venv 入门——隔离项目依赖的正确姿势

刚学 Python 时，很多人都是把所有包一股脑装进系统 Python 里。起初很顺手，直到某天旧项目突然跑不起来，才发现是新装的某个库升级了依赖，把旧项目的环境“污染”了。虚拟环境 venv 就是用来解决这个问题的：一个项目一套独立环境，互不干扰。

venv 到底是什么

venv 是 Python 3.3 之后自带的标准库，不用另外安装。它会在项目目录下创建一个独立的 Python 环境，里面有属于自己的解释器入口和包安装目录。激活后，python 和 pip 指的都是这个环境里的版本，装包、升级都只影响当前项目，系统 Python 保持干净。理解这一点就够了：venv 不是新语言，也不是容器，它只是一套“隔离规则”。

三步创建并激活

在项目根目录执行创建命令，名字习惯用 .venv，一眼就能看出它是环境目录：

python -m venv .venv

创建完成后需要激活。Windows 和 macOS、Linux 的命令不一样，照着自己的系统选一句：

# Windows PowerShell
.venv\Scripts\Activate.ps1

# macOS / Linux
source .venv/bin/activate

激活成功后，命令行前面会出现 (.venv) 提示。此时执行 which python（Windows 用 where python），看到的路径应该指向项目里的 .venv，这就说明已经进入隔离环境。

装包、冻结与复现

激活后就和平常一样用 pip，但要养成两个习惯。第一，装包前先确认提示符里有 (.venv)，避免一不小心装进全局环境；第二，装完把依赖写进清单：

pip install requests
pip freeze > requirements.txt

换一台电脑或者同事接手项目时，不需要逐个回忆装过什么，只要新建 venv、激活，再执行一句就能复现：

pip install -r requirements.txt

更稳妥的做法是固定版本号，例如把 requests==2.32.3 写进清单，而不是只写包名。这样无论过多久重建，装到的都是同一套版本，行为更可预期。

容易踩的几个坑

第一，激活只对当前终端窗口生效，新开一个终端要重新激活；第二，虚拟环境一般不提交到版本库，要在 .gitignore 里加上 .venv/，只提交代码和 requirements.txt；第三，环境坏了不用修，直接删掉 .venv 文件夹重新创建，比逐个排查依赖冲突快得多。

另外，编辑器也要选对解释器。以 VS Code 为例，需要把解释器指向项目里 .venv/bin/python，否则编辑器提示正常、终端运行却报错，问题往往就出在这里。还有一点：venv 绑定创建它时的 Python 版本，升级 Python 后，旧环境不会自动跟着升级，需要重新创建。

一个可照做的流程

新建项目时，按这个顺序走基本不会错：创建项目目录、执行 python -m venv .venv、激活、升级 pip、安装依赖、冻结到 requirements.txt。等到项目越来越多，你会发现每个项目都有自己的“小房间”，升级某个库不用再担心牵连别的项目，排查问题时也能先问一句：我现在到底在哪个环境里？

把环境隔离变成习惯，成本很低，收益却会跟着项目数量一起放大。这也是 Python 开发里最值得先养成的姿势之一。