Python 虚拟环境 venv：一个命令告别"依赖打架"

刚学 Python 的人迟早会撞上同一堵墙：A 项目要 requests 2.28，B 项目要 requests 2.31；装了这个，另一个就报错。更糟的是 pip install 装进全局环境，哪天手滑升级了一个库，别的项目跟着一起坏。虚拟环境就是来解决这个问题的：给每个项目一个独立的"小房间"，依赖互不干扰。

一、虚拟环境到底是什么

一句话：虚拟环境就是一份独立的 Python 解释器副本加一套独立的包目录。激活它之后，python 和 pip 指的都是这个环境里的版本，装包只装进当前项目，不动系统全局。项目删了，环境跟着删，干干净净。

Python 3.3 起自带 venv 模块，不用额外安装，标准流程就四步：创建、激活、装包、退出。

二、创建和激活：三行命令

在项目目录下执行：

python -m venv .venv

这会在当前目录生成一个 .venv 文件夹，里面是一套完整的 Python 环境。接着激活它。Linux 和 macOS：

source .venv/bin/activate

Windows：

.venv\Scripts\activate

激活成功后，命令行前面会出现 (.venv) 这样的前缀，这就是"我在虚拟环境里"的标志。退出时输入 deactivate 即可，前缀消失，回到全局环境。

三、在环境里装包，和平时一样

激活之后，pip 的行为和平时完全一样，只是装包位置变了：

pip install requests
pip list
pip freeze > requirements.txt

pip freeze 把当前环境装了什么、什么版本全部导出到 requirements.txt。别人拿到你的项目，一条命令就能还原出同样的环境：

pip install -r requirements.txt

这是团队协作的标配动作：代码仓库里永远带一份 requirements.txt，新人上手先建虚拟环境再装依赖，不再有"在我机器上能跑"的扯皮。

四、两个容易踩的坑

第一个坑：用错 pip。没激活虚拟环境就 pip install，包装进了全局。每次装包前先看一眼命令行有没有 (.venv) 前缀，养成习惯能省很多排查时间。也可以用 python -m pip install 代替 pip，这样一定用的是当前 python 对应的 pip，不会串到别的版本。

第二个坑：把 .venv 提交进 Git。虚拟环境动辄几百兆，而且和操作系统绑定，换台机器就不能直接用。项目根目录的 .gitignore 里加一行 .venv/，只提交代码和 requirements.txt，环境到哪都能重建。

五、venv 和 conda 怎么选

新手常问 venv 和 conda 选哪个。简单分：只做纯 Python 开发，venv 够了，轻量、零安装、标准库自带；要装 numpy、pytorch 这类带 C 扩展和系统依赖的科学计算包，或者要在多版本 Python 之间切换，conda 更省心。两者不冲突，很多项目 venv 管 Python 包、系统包管理器管别的，各司其职。

小结

虚拟环境的习惯越早养成越好：一个项目一个环境，创建用 python -m venv .venv，激活看 (.venv) 前缀，依赖用 requirements.txt 锁定和还原。等你同时维护三四个项目的时候，就会庆幸自己从一开始就没把依赖全堆在全局环境里。