Python 虚拟环境 venv 入门：一个项目一套依赖，不再互相打架

刚学 Python 时，很多人都会把所有包一股脑装进系统 Python。第一个项目用 requests 2.28，第二个项目却要求 requests 2.31；升级了，A 项目能跑，B 项目却报接口变了。问题不在代码，而在环境没有隔离。Python 自带的 venv，就是用来解决这件事的最轻量工具。

venv 是什么

venv 是 Python 3.3 起内置的虚拟环境工具，不需要额外安装。它会在项目目录下复制一份解释器和标准库，并建一个独立的 site-packages。从此这个项目装什么包、装哪个版本，都只影响它自己，系统 Python 和别的项目互不干扰。

三步建一个环境

先进入项目目录，执行创建命令，名字习惯用 .venv：

python -m venv .venv

Windows 上激活：

.venv\Scripts\activate

macOS 或 Linux 上激活：

source .venv/bin/activate

激活成功后，命令行前面会出现 (.venv) 字样，说明当前终端已经进入这个环境。用完退出也很简单，输入 deactivate 即可。

在环境里装包

激活之后再用 pip，包就会装进当前环境：

pip install requests
pip list

想把环境原样交给同事或换台电脑重建，先冻结依赖：

pip freeze > requirements.txt

对方拿到项目后，只要创建并激活同名环境，再执行 pip install -r requirements.txt，就能得到同一套依赖。这一步是团队协作里最容易被忽略、也最有用的习惯。

三个常见坑

第一，忘记激活就 pip install，包又装回了全局。装包前先看提示符有没有 (.venv)，不确定就执行 python -m pip list，确认路径指向 .venv 里的解释器。

第二，把 .venv 提交进 Git。虚拟环境体积大、且与操作系统绑定，别人用不上。正确做法是在 .gitignore 里加一行 .venv/，只提交代码和 requirements.txt。

第三，环境坏了舍不得删。venv 本身不含项目代码，删掉重建只要一两分钟。依赖装乱了、解释器版本选错了，直接删掉 .venv 目录重新创建，往往比逐个排错更快。

一个顺手的工作流

我的习惯是：新建项目先建环境，再写第一行代码；装包后随手更新 requirements.txt；换电脑先看 requirements.txt 里有没有漏记的包。坚持几周之后，换环境、接手旧项目、帮同事复现问题都会轻松很多。

虚拟环境不是什么高深技术，它只是一个好习惯的载体：一个项目一套依赖，互不打扰、可复现、可丢弃。先把 venv 用顺手，再去学更重的包管理工具也不迟。