Python 虚拟环境入门：venv 让项目依赖不再打架

做过 Python 项目的人大概率都遇过这种场景：A 项目要 requests 2.28，B 项目要 requests 2.31，装了这个那个就跑不起来；或者自己写的脚本能跑，同事拿过去就报缺包。这些问题的根源都是把所有包装进了同一个全局环境里。今天用最短的篇幅讲清楚虚拟环境是什么、怎么用、怎么复现。

一、为什么需要虚拟环境

Python 的包默认装到解释器对应的全局 site-packages 目录里，所有项目共享。项目一多必然冲突：不同框架要求的依赖版本不一样，升级了新版就可能把老项目搞挂。虚拟环境的思路很简单——给每个项目单独开一块"包目录"，装包、卸包都只影响这一块，互不干扰。Python 3.3 之后官方自带 venv 模块，不用额外安装任何东西。

二、三条命令跑起来

假设项目目录是 myproject，只需三步：

1. 进入项目目录，创建虚拟环境：

python -m venv .venv

执行后会在 .venv 目录里生成一套独立的环境，之后所有包都装在这里面。

2. 激活虚拟环境：

.venv\Scripts\activate      （Windows）
source .venv/bin/activate   （macOS/Linux）

激活成功后，命令行前面会多一个 (.venv) 前缀。这一步是关键——只有激活了，pip 装的包才会落到这个环境里。

3. 正常用 pip 装包：

pip install requests

三、几个容易踩的坑

坑 1：忘了激活就装包。 装完发现全局环境又脏了。判断方法很简单：看命令行有没有 (.venv) 前缀，或者用 pip -V 查看路径里有没有 .venv。

坑 2：把虚拟环境提交到 git。 .venv 目录动辄几百兆，还和操作系统强相关。正确做法是提交 requirements.txt 依赖清单，别人克隆后自己创建环境再安装：

pip freeze > requirements.txt        # 生成依赖清单
pip install -r requirements.txt      # 一键安装

坑 3：换机器后环境复现。 只需要两步：先 python -m venv .venv 创建新环境，激活后 pip install -r requirements.txt。装的是什么、什么版本，全在清单里，完全可复现。

四、进阶方向

如果机器上项目很多，可以了解 virtualenvwrapper；做依赖锁定和发布，可以看 Poetry、uv 这类工具。但对新手来说，venv + requirements.txt 已经完全够用——它是 Python 自带的，零额外依赖。等真正体会到"每个项目一个环境"的好处后，再去升级工具链不迟。

写在最后

虚拟环境是 Python 工程化的第一课，十条命令以内就能让依赖冲突彻底消失。建议现在就找个项目走一遍：创建、激活、装包、freeze 导出，四步走完，以后就不会再被"在我电脑上明明能跑"困扰了。