Python 新手必会的虚拟环境 venv：从创建到避坑实战

学 Python 最常见的翻车现场：教程里 pip install 装得好好的，换个项目就报错；或者给新项目装了个库，旧项目直接跑不起来。问题往往不在代码，而在所有项目共用同一个 Python 环境。虚拟环境 venv，就是给每个项目单独开一间“小房间”，库互不打架。

为什么一定要用虚拟环境

第一，隔离依赖。A 项目要用 requests 2.28，B 项目要用 2.31，同一个环境里只能装一个版本，迟早有人要妥协；分开后各用各的，谁也不影响谁。

第二，干净可复现。环境里的包装进 requirements.txt，换台电脑照单全装，别人接手项目也不用猜你装了什么。

第三，不污染系统 Python。系统自带工具也依赖系统 Python，在里面乱装乱升级，可能把系统工具搞坏，却很难排查。

完整流程：创建、激活、装包、退出

在项目根目录创建环境，名字习惯用 .venv：

python -m venv .venv

激活它。Windows 和 macOS/Linux 命令不一样：

# Windows
.venv\Scripts\activate
# macOS / Linux
source .venv/bin/activate

激活成功后，命令行提示符前面会出现 (.venv)，这就是你在虚拟环境里的标志。然后再装包，并把版本冻住：

python -m pip install --upgrade pip
pip install requests
pip freeze > requirements.txt

用完退出，一个命令：

deactivate

在新电脑上复现也一样：创建、激活、按清单装包，三步就够：

pip install -r requirements.txt

新手常踩的 3 个坑

坑一：在没激活的环境里装包。装的时候很顺利，运行时 import 却找不到，因为包装进了全局环境，项目用的 venv 里根本没有。装包前先看提示符有没有 (.venv)，不确定就用 pip -V 或 which python 看看路径是不是项目下的 .venv。

坑二：把 .venv 提交到 Git 或打包发给别人。虚拟环境体积大，还包含本机的绝对路径，别人拿到也用不了。正确做法是在 .gitignore 里加一行 .venv/，仓库里只留 requirements.txt。

坑三：用错 Python 版本创建环境。python 指向系统旧版本，建出来的 venv 自然也是旧版；或者装了新版 Python 却一直用旧的 python 创建，版本问题会一直跟到项目里。创建前先 python --version 确认，需要指定版本就用 python3.11 -m venv .venv 这样的形式。如果不同项目需要不同的 Python 大版本，venv 本身管不了版本，要配合 pyenv 或 conda。

记住一句话

一个项目一个 venv，激活了再装包，.venv 不进仓库。养成这个习惯，换电脑、换项目、接手别人的项目，都是创建、激活、装包三条命令的事，出问题的概率会少一大半。