Python 虚拟环境 venv 入门：隔离依赖，从此告别“在我电脑上能跑”

刚学 Python 时，很多人都踩过同一个坑：项目 A 要用 requests 2.28，项目 B 却要求 2.31；装了一个新库，另一个项目突然跑不起来；换一台电脑，代码又报 ModuleNotFoundError。这些问题的根子不在代码，而在环境——所有项目共用同一套全局 Python 解释器和 site-packages，依赖互相打架。解决办法就是给每个项目一个独立的“小房间”：虚拟环境。Python 3.3 起自带的 venv 模块不用装任何第三方工具，就能做到这一点。

一、venv 到底做了什么

venv 会在项目目录里复制一份轻量 Python 解释器，并生成独立的 site-packages 目录。激活后，pip 安装的包只进这个目录，不会污染全局环境；退出后，系统又回到原来的 Python。每个项目各用各的依赖，互不干扰。虚拟环境不是虚拟机，它不虚拟硬件，只隔离 Python 包和解释器路径，所以创建只要几秒，删除也只是一个文件夹。

二、三步创建一个虚拟环境

先确认 Python 版本：

python --version

在项目根目录创建并命名为 .venv：

python -m venv .venv

Linux 或 macOS 上激活：

source .venv/bin/activate

Windows 上激活：

.venv\Scripts\activate

激活成功后，命令行前面会出现 (.venv) 这样的提示符。这时再装包：

pip install requests
python -m pip install --upgrade pip

用完退出很简单，输入 deactivate 即可，提示符恢复原样。

三、让环境可以复现

虚拟环境本身不需要、也不应该提交到代码仓库。真正要留下来的是依赖清单。装好包后导出：

pip freeze > requirements.txt

同时把 .venv 写进 .gitignore。换一台电脑时，别人只需要三步：拉代码、创建虚拟环境、执行 pip install -r requirements.txt，就能得到和你一样的依赖组合。能不能复现，是判断一个项目是否“专业”的重要标志。

四、新手最容易踩的五个坑

第一，忘记激活就 pip install，包全装进了全局环境，项目换个地方还是跑不起来。装包前先看一眼命令行有没有 (.venv)。第二，在虚拟环境里还用 sudo pip install，权限和路径都会乱套，普通用户权限完全够用。第三，把 .venv 提交进 Git，仓库瞬间多出几千个文件，别人也用不了，因为虚拟环境里的路径是写死的。第四，一个环境用到老，多个项目共用一个 venv，等于又回到了全局安装的老路。第五，环境坏了不敢删，其实 venv 的修复成本极低：删掉 .venv 文件夹，按 requirements.txt 重建一个，几分钟就恢复。

五、venv、virtualenv 和 conda 怎么选

venv 是标准库自带，够用、够轻，适合绝大多数纯 Python 项目。virtualenv 功能更丰富，支持更老的 Python 版本和更快的创建速度，老项目里常见。conda 则面向数据科学场景，能管理 Python 之外的系统级依赖和非 Python 包，安装体量也更大。对刚入门的开发者，我的建议是：先把 venv 用熟，理解“隔离”这件事，再根据项目需要去学别的工具。工具会变，隔离依赖的思路不会变。

小结

虚拟环境解决的不是“怎么写代码”，而是“代码在哪里跑、用什么依赖跑”。养成习惯其实很简单：新建项目先 python -m venv .venv，激活后再装包，定期更新 requirements.txt。等你同时维护三四个项目、或者第一次在别人的电脑上成功复现自己的环境时，就会明白这几分钟的投入有多值。