Python 入门：虚拟环境不是可选项——从一次依赖冲突说起

上周帮同事看一个报错：同一段代码，在他电脑上跑得好好的，换到另一台电脑就报 ModuleNotFoundError。检查之后发现，问题不在代码，而在环境——两台电脑上安装的 requests 版本不一样，一个是 2.28，一个是 2.32，某个接口的行为刚好变了。这种“在我电脑上能跑”的问题，Python 初学者几乎都会遇到一次，而解法其实很简单：给每个项目一个独立的虚拟环境。

什么是虚拟环境？可以把它理解成一个项目专属的“小房间”。Python 自带的 venv 模块能在这个房间里再装一份解释器和一套依赖，项目 A 用 requests 2.28，项目 B 用 requests 2.32，互不干扰。你不再需要在全局环境里反复卸载重装，也不用担心给一个项目升级依赖时，顺手把另一个项目弄坏。

新建一个虚拟环境只需要三步。先进入项目目录，运行 python -m venv .venv，这会在项目里生成一个 .venv 文件夹；然后激活它，Windows 上是 .venv\Scripts\activate，macOS 和 Linux 上是 source .venv/bin/activate，激活成功后命令行前面会出现 (.venv)；最后在这个状态下用 pip install 安装依赖，装的东西只会进当前环境。做完用 deactivate 退出。把这三步练熟，比背十条 pip 参数都有用。

环境建好了，还要能“复现”。养成一个习惯：依赖装完就执行 pip freeze > requirements.txt，把当前环境的依赖和版本冻结下来。换电脑、换同事接手时，只要新建虚拟环境再执行 pip install -r requirements.txt，就能得到同一套依赖。很多教程只讲安装，不讲冻结，于是每一次换环境都像开盲盒。requirements.txt 就是让环境可复制的那张清单，顺手把它和代码一起提交到版本库。

新手最容易踩的坑有三个。第一，直接用系统自带的 Python 装包。系统 Python 常常被系统工具依赖，乱装乱升级可能影响系统本身，尽量用官方安装包或版本管理工具另装一个 Python，再在上面建虚拟环境。第二，激活了环境，pip 却还是全局的。激活后先运行 python -m pip --version 和 which python（Windows 用 where python），确认路径指向 .venv 里面，再安装。第三，把 .venv 文件夹提交进 Git。这个文件夹可能有几百兆，别人也用不上，一定要在 .gitignore 里加上一行 .venv/。

最后给自己留一个检查清单。开始一个新项目时，先问三句话：这个项目有自己的虚拟环境吗？依赖有没有冻结到 requirements.txt？换一台电脑能不能一键复现？如果三个答案都是肯定的，依赖冲突就很难再找上你。虚拟环境不是可选项，它是写 Python 的基本工作方式，越早养成习惯，后面返工越少。

从今天起，每新建一个 Python 项目，先建虚拟环境，再写第一行代码。这个顺序一旦固定下来，你会发现很多莫名其妙的报错，其实从来就不是代码的问题。