Python 虚拟环境 venv：每个项目都该有一个「独立小房间」

刚开始学 Python 的时候，我犯过一个很典型的错误：把所有项目都装在同一台电脑的全局环境里。第一个项目要用 requests 2.x，第二个项目要用 requests 1.x，升级一个就弄坏另一个，最后只能重装 Python 收场。后来我才明白：每个 Python 项目，都值得拥有一个独立的「小房间」——这就是虚拟环境。

什么是虚拟环境？可以把它理解成给项目单独划出的一块地盘。里面的 Python 解释器和第三方库只属于这个项目，装什么、升级什么，都不会影响别的项目，也不会污染系统全局环境。Python 自带的 venv 模块就是做这件事的，不需要再安装任何额外工具。

创建虚拟环境非常简单，在项目根目录执行：

python -m venv .venv

这条命令会在当前目录生成一个 .venv 文件夹，里面是一份独立的 Python 运行环境。接下来要「走进这个房间」，也就是激活它：

Windows（PowerShell）：.venv\Scripts\Activate.ps1

macOS / Linux：source .venv/bin/activate

激活成功后，命令行提示符前面会出现 (.venv) 字样，说明你已经在虚拟环境里了。

在虚拟环境中，pip 安装的任何包都只属于当前项目：

pip install requests
pip list

开发完成后，把依赖「打包带走」也很重要：

pip freeze > requirements.txt

换一台电脑或者把项目分享给同事时，对方只需执行 pip install -r requirements.txt，就能还原出完全一致的依赖环境。当天工作结束想退出虚拟环境，输入 deactivate 即可。

几个值得养成的习惯：第一，把虚拟环境目录统一命名为 .venv，并写进 .gitignore，永远不要把 .venv 提交到代码仓库；第二，为开发环境和生产环境准备不同的依赖文件，比如 requirements-dev.txt；第三，创建新项目的第一件事就是先建虚拟环境，而不是等依赖冲突了再补救。

虚拟环境不会让代码跑得更快，但它能让环境问题少九成。当你习惯了「一个项目一个环境」，很多莫名其妙的报错——比如明明装了包却提示找不到——都会自然消失。这正是 Python 工程化最简单、也最有效的一步。