Python 虚拟环境 venv 入门：为什么每个项目都该有一个

刚开始学 Python 的时候，很多人都是把所有第三方库直接装到系统 Python 里。项目一多，问题就来了：A 项目需要 requests 2.28，B 项目的老代码却只兼容 2.20；某天随手升级了一个库，另一个项目突然就跑不起来了。这类「在我电脑上明明能跑」的依赖冲突，根源就是所有项目共用同一套环境。虚拟环境就是解决这个问题的标准做法：为每个项目创建一个独立的 Python 环境，库装在项目自己的小房间里，互不干扰。

Python 3.3 之后内置了 venv 模块，不需要额外安装任何工具。在项目目录下执行 python -m venv .venv，就会生成一个 .venv 文件夹，里面包含一份独立的 Python 解释器副本和 pip。接下来要激活它：Windows 在 PowerShell 里执行 .venv\Scripts\Activate.ps1，macOS 和 Linux 执行 source .venv/bin/activate。激活成功后，命令行提示符前面会出现 (.venv) 字样，这时再用 pip install 安装的库只会进入当前虚拟环境，不会污染系统环境；活干完了，执行 deactivate 即可退出。

依赖装好之后，别忘了把环境「存档」。执行 pip freeze > requirements.txt，会把当前环境里所有库及版本写进文件。别人拿到项目，或者你换了一台电脑，只需要在新环境里执行 pip install -r requirements.txt，就能一键还原完全相同的依赖组合。配合 Git 使用时，.venv 文件夹本身不要提交，把它写进 .gitignore，只提交 requirements.txt 就够了。

几个新手常踩的坑：一是忘了激活环境就 pip install，库装到了系统里，运行时还是报 ModuleNotFoundError，排查时先看提示符有没有 (.venv)；二是把虚拟环境文件夹改名或挪位置，里面的脚本写的是绝对路径，挪完就失效，正确做法是删掉重建；三是系统里装了多个 Python 版本，创建时要用目标版本的那支解释器来执行 -m venv，比如 py -3.11 -m venv .venv。

养成「一个项目一个虚拟环境」的习惯，成本只有一条命令，却能省掉大量依赖地狱里的排查时间。从今天开始，新建任何 Python 项目时，先建 venv，再写代码。