Python 虚拟环境 venv 一次讲明白：隔离、创建与三个常见坑

装了两个 Python 项目，一个要 requests 2.x，一个要 3.x，pip 装来装去总冲突？问题不在 pip，在你没用虚拟环境。venv 是 Python 自带的隔离工具，一个项目一套依赖，互不干扰。

1. 为什么需要虚拟环境

全局装包最大的麻烦是版本打架：项目 A 依赖库 X 1.0，项目 B 依赖库 X 2.0，全局环境只能留一个版本。虚拟环境给每个项目一个独立的 site-packages，装什么版本自己说了算，系统 Python 干干净净。

2. 创建与激活：三条命令

# 在项目目录下创建虚拟环境（名字常用 .venv 或 venv）
python3 -m venv .venv
# 激活：Linux / macOS
source .venv/bin/activate
# 激活：Windows PowerShell
.venv\Scripts\Activate.ps1

激活后命令行前面会出现 (.venv) 标志，这时 pip install 装的包只进当前环境。退出用 deactivate，删除环境直接删掉 .venv 目录就行，干净利落。

3. 坑一：用错了 pip

激活后先确认 pip 属于当前环境：

which pip   # 应指向 .venv/bin/pip
pip --version

如果 which pip 指向系统路径，说明没激活成功就装了包——包进了全局环境，项目里还是找不到。每次装包前看一眼命令行前的 (.venv)，养成习惯。

4. 坑二：把 .venv 提交进 Git

虚拟环境目录动辄几百 MB，绝不能进版本库。项目根目录建 .gitignore，第一行就写：

.venv/

同时用 pip freeze > requirements.txt 锁定依赖，别人克隆项目后 pip install -r requirements.txt 就能一键还原同样的环境。

5. 坑三：venv 与 conda 混用

conda 也有自己的环境管理，和 venv 混用容易出现 Python 解释器指向混乱：明明激活了 venv，python 却跑的是 conda 的。原则很简单：一个项目只选一种工具。新手建议先用 venv——它是标准库自带、零安装；等要用到科学计算的复杂依赖时再考虑 conda。

结语

venv 的链条很短：创建 → 激活 → 装包 → freeze 锁定。虚拟环境不是高级技巧，而是 Python 项目的默认姿势。你第一次被依赖冲突坑过吗？评论区聊聊。