Python 虚拟环境入门：用 venv 给每个项目一间“独立办公室”

一、为什么需要虚拟环境

很多 Python 新手都遇到过这样的场景：项目 A 依赖 requests 2.25，项目 B 依赖 requests 2.31，装在同一个全局环境里，必然有一个跑不起来；又或者 pip install 一时爽，三个月后要迁移服务器，却说不清装过哪些包、什么版本。

虚拟环境解决的就是这个问题——给每个项目一间“独立办公室”：独立的 Python 解释器入口、独立的 site-packages、独立的 pip。项目之间互不打扰，搬家也方便。

Python 3.3 之后标准库自带 venv 模块，不用额外安装任何东西，一条命令就能开工。

二、三步创建并进入环境

# 1. 在项目目录下创建虚拟环境（会生成 .venv 目录）
python -m venv .venv

# 2. 激活（Linux / macOS）
source .venv/bin/activate

# 2. 激活（Windows PowerShell）
.venv\Scripts\Activate.ps1

# 3. 安装依赖，只装进这个环境
pip install requests

激活成功后，命令行提示符前面会出现 (.venv) 标记。此时 which python（Windows 用 where python）指向的已经不是系统解释器，而是 .venv 里的那一份。

退出环境用 deactivate，目录还在，随时可以再进。

三、依赖清单：requirements.txt 的正确用法

环境本身不适合跟着项目走，能跟着项目走的是清单：

# 导出当前环境的全部依赖及版本
pip freeze > requirements.txt

# 在新机器上一次性还原
pip install -r requirements.txt

建议把 .venv 目录加进 .gitignore，只提交 requirements.txt。环境是可再生的，清单才是需要版本管理的东西。

四、三个新手常见坑

1. 换了终端就“失效”：虚拟环境不是持久状态，每开一个新终端都要重新 activate。用 VS Code 打开项目时，在右下角选择 .venv 里的解释器，新开的终端会自动激活，能省不少事。

2. PowerShell 报“禁止运行脚本”：Windows 执行策略默认受限，执行 Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser 放开即可，只对当前用户生效，不影响系统全局。

3. 忘记激活就装包：结果包装到了全局环境。装完依赖后随手 pip list 检查一下，如果发现环境里只有 pip、setuptools 两三个包，多半是激活这一步漏了。

五、小结

venv 的哲学很简单：项目之间靠物理隔离避免依赖打架，靠 requirements.txt 保证可复现。个人项目和小团队用它完全够用；等真正需要精确锁死传递依赖的版本时，再了解 pip-tools 或 uv 也不迟。从下一个新项目开始，把 python -m venv .venv 变成肌肉记忆吧。