Python 虚拟环境 venv 入门：一个项目一套依赖，告别版本冲突

刚学 Python 的时候，我常遇到一个怪现象：上周还能跑的代码，这周换个项目就报错；明明本地装了某个库，换台电脑却提示找不到。后来才明白，问题大多出在“所有项目共用同一套全局 Python 环境”上。解决办法并不复杂：给每个项目建一个独立的虚拟环境，而 Python 自带的 venv，就是最轻量、最不需要额外安装工具的入门选择。

一、为什么需要虚拟环境

全局环境像一间公共厨房：项目 A 需要 requests 2.28，项目 B 却依赖某个只兼容 requests 2.25 的老库，两个版本装在同一处必然打架。虚拟环境则是给每个项目单独开一间小厨房，解释器和第三方库互不干扰。出了问题，删掉重建即可，不会影响系统 Python 和其他项目。venv 是 Python 3.3 起内置的标准库，不用装 virtualenv，也不用记太多概念，适合新手先把“隔离”这件事做起来。

二、创建：一条命令就够了

先进入项目目录，再执行创建命令。习惯上把环境放在项目根目录下，名字常用 .venv 或 venv，前者带点号，默认会被很多工具视为隐藏目录，列表看起来更清爽：

python -m venv .venv

命令里的 -m 表示以模块方式运行 venv，.venv 是环境目录名。创建完成后，目录里会出现一份独立的 Python 解释器副本和 pip，之后在这个环境里装的包，只会落到这个目录中。注意：创建命令本身不联网，速度很快；如果提示找不到 python，可改用 python3 试试，并确认 Python 版本在 3.8 以上。

三、激活：让终端先“走进”这个环境

创建只是建好了房间，激活才是搬进去。不同系统命令不同：

Windows（PowerShell）：.venv\Scripts\Activate.ps1

Windows（CMD）：.venv\Scripts\activate.bat

macOS / Linux：source .venv/bin/activate

激活成功后，终端提示符前面会出现 (.venv) 字样，这就是最直观的判断标准。此后执行的 python 和 pip，都指向虚拟环境里的那一份。退出时输入 deactivate 即可，环境本身不会被删除，下次再激活就能继续用。

四、装包、导出与复现

激活后装包，和平时一样：

pip install requests

pip freeze > requirements.txt

第一行装包，第二行把当前环境里所有包及精确版本写进 requirements.txt。把它和代码一起提交，别人才可以用下面两步在自己的电脑上复现出同样的环境：

python -m venv .venv

source .venv/bin/activate

pip install -r requirements.txt

升级某个包用 pip install -U 包名，查看已装包用 pip list。养成“改依赖就更新 requirements.txt”的习惯，协作时能少很多“在我电脑上明明能跑”的争论。

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

第一，忘记激活就装包：装进了全局环境，项目里还是找不到。装包前先看提示符有没有 (.venv)。第二，把 .venv 提交进了 Git：环境目录可能有上万个文件，又大又没必要，应在 .gitignore 里加一行 .venv/。第三，编辑器选错了解释器：在 VS Code 等工具里，要把解释器手动选为项目下 .venv/bin/python，否则编辑器提示和终端运行的是两套环境。第四，环境坏了舍不得删：依赖冲突、误删文件时，直接删除 .venv 目录，按上面三步重建，往往比逐个排错更快。

六、一个顺手的工作流

我的习惯是：新建项目先建虚拟环境，再写第一行代码；每个项目一个 .venv，名字统一；requirements.txt 随代码一起维护；部署或换电脑时按“建环境、激活、装依赖”三步走。这套流程没有额外工具成本，却能把“版本冲突”“换电脑跑不起来”这类问题挡在门外。等你熟悉之后，再去了解 pipenv、poetry、uv 也不迟，它们解决的是更复杂的依赖管理问题，而 venv 教会你的，是隔离这件事本身。

小结：虚拟环境不是什么高深技术，它只是一个朴素的原则——一个项目，一套依赖，互不打扰。花十分钟学会 venv，以后每新建一个 Python 项目，先 python -m venv .venv，再激活、装包，你会发现很多莫名其妙的环境问题，从此不再出现。