Python 虚拟环境入门：从混乱到干净的项目隔离

很多 Python 新手都有过类似经历：A 项目要用 requests 的旧版本，B 项目却要求新版本；换一台电脑跑代码，明明装过依赖，运行时还是报错。问题往往不在代码本身，而在环境没有隔离。虚拟环境就是为每个项目准备一个独立的 Python 运行空间，让依赖互不干扰。

虚拟环境是什么

可以把系统 Python 理解成公共厨房，把虚拟环境理解成每个项目自己的小厨房。创建虚拟环境后，解释器、pip 和已安装的包都会放在项目专属目录里。在这个环境里安装、升级或删除包，只影响当前项目，不会动系统 Python，也不会影响其他项目。需要说明的是，虚拟环境并不是容器，也不是虚拟机，它更轻量，创建和删除都很快，适合日常开发。

创建与激活

Python 3.3 之后自带 venv，不需要额外安装。先进入项目目录，再创建名为 .venv 的环境：

python -m venv .venv

创建完成后需要激活。Windows 上常用 PowerShell 命令是：

.venv\Scripts\Activate.ps1

macOS 和 Linux 上则是：

source .venv/bin/activate

激活成功后，终端提示符前面会出现 (.venv)。这时再用 python 和 pip，用的就是虚拟环境里的版本。退出时输入 deactivate 即可。判断是否激活，最直观的方法是看提示符，也可以执行 which python 或 where python，确认路径指向项目目录下的 .venv。

安装依赖与固定版本

激活后安装包的姿势和平时一样，例如 pip install requests。但只安装还不够，团队协作时还要固定版本，否则别人装到的可能是更新的版本。常用做法是把依赖写进 requirements.txt：

pip freeze > requirements.txt

新环境还原时执行 pip install -r requirements.txt。需要注意，pip freeze 会列出所有已安装的包，包括间接依赖，文件可能比较长。小型项目可以直接使用，稍大的项目可以只手写直接依赖，再配合锁定工具管理间接依赖。把 requirements.txt 提交到版本控制，把 .venv 排除在外，是更干净的做法。

常见问题

第一，Windows 激活被阻止。PowerShell 默认执行策略可能禁止运行脚本，可以先检查策略设置，确认当前用户允许本地脚本后再激活，不要为了图省事随意放宽到全局不受限。第二，提示找不到模块。先确认终端是否已激活虚拟环境，再确认安装和运行用的是同一套解释器，很多问题都是编辑器选了系统 Python，而终端装在虚拟环境里。第三，包版本冲突。不要反复用新版本覆盖旧版本，先看报错里冲突的包名和版本范围，必要时新建一个干净环境重装，比在脏环境里修补更省时间。第四，.venv 越来越大。虚拟环境本身不需要提交，删除后随时可以按 requirements.txt 重建。

养成三条习惯

一是每个项目一个环境，项目一开始就创建，不要等到冲突了才补。二是把 .venv 加入 .gitignore，只提交代码和依赖清单。三是换电脑或交接项目时，先验证能否从 requirements.txt 完整还原，再说环境没问题。虚拟环境不是高深技术，而是一种秩序感：它把每个项目的依赖边界划清楚，后续调试、升级和协作都会轻松很多。从今天起，给每个新项目先建一个虚拟环境，你会发现很多莫名其妙的报错其实早就消失了。