Python 虚拟环境入门：venv 的使用与常见问题

在 Python 开发中，不同项目往往依赖不同版本的库，甚至需要不同版本的 Python 本身。如果把所有包都装进系统全局环境，项目之间很容易互相干扰，升级一个库就可能破坏另一个项目。虚拟环境正是为了解决这个问题：它为每个项目创建一个独立的包目录，让依赖互不影响。Python 3.3 之后自带的 venv 模块，不需要安装第三方工具，是入门最稳妥的选择。

创建虚拟环境非常简单。在项目目录下执行 python -m venv .venv，就会在当前目录生成一个名为 .venv 的文件夹，里面包含独立的 Python 解释器和 pip。命名上，.venv、venv、env 都很常见，我更推荐 .venv，因为它默认会被很多工具识别，也便于在 .gitignore 里统一忽略。创建完成后不要直接使用系统 pip，关键一步是先激活环境。

激活方式因系统而异。Windows 上执行 .venv\Scripts\activate，成功后命令行前面会出现 (.venv) 提示；macOS 与 Linux 上执行 source .venv/bin/activate，效果相同。激活后，python 和 pip 都指向虚拟环境内部，安装的包只会进入该环境。此时执行 pip install requests，包就会装到 .venv/lib 中，而不是全局。项目完成或切换项目时，执行 deactivate 即可退出，提示符恢复正常。

要把环境复现给同事或部署到服务器，依赖清单必不可少。开发过程中随时用 pip freeze > requirements.txt 生成清单，新环境里先创建并激活 venv，再执行 pip install -r requirements.txt，就能得到基本一致的依赖。需要注意，freeze 会记录当前环境所有包，包括间接依赖，清单可能很长；如果希望清单更干净，可以只记录直接依赖，或者使用 pip-tools 等工具分层管理。

常见问题第一类是激活失败。Windows PowerShell 经常因为执行策略报错，提示无法加载脚本，这时可以在管理员 PowerShell 中执行 Set-ExecutionPolicy RemoteSigned -Scope CurrentUser，或者改用命令提示符执行 activate.bat。macOS 或 Linux 上如果提示权限不足，通常是路径或脚本没有执行权限，检查是否用错了 Windows 路径，或者重新创建环境。

第二类问题是装了包却找不到。最常见的原因是没有激活环境，或者在编辑器里选错了解释器。解决办法是先确认命令行前面有没有 (.venv)，再用 which python 或 where python 查看解释器路径，最后在 VS Code 等编辑器里把解释器手动指向 .venv/bin/python 或 .venv\Scripts\python.exe。另一个常见误区是在虚拟环境里升级 pip 后仍然报错，这时先执行 python -m pip install --upgrade pip，确保用的是环境内的 pip。

第三类问题与项目管理有关。虚拟环境文件夹体积较大，不应该提交到 Git，一定要在 .gitignore 中加入 .venv/。如果环境损坏或依赖混乱，最简单的办法是删除 .venv 文件夹并重新创建，这比逐个排查包冲突更快。不要把虚拟环境移到别的路径后继续使用，因为其中部分脚本记录了绝对路径，移动后容易失效。

总结一下规范流程：一个项目一个环境，创建后先激活再安装，定期导出 requirements.txt，环境出问题就重建。养成这个习惯，Python 项目的依赖管理会清晰很多，也能避免大量难以定位的环境问题。