新项目先建虚拟环境：Python 依赖隔离的三条实战规则

很多 Python 初学者的第一个坑不是语法，而是依赖：A 项目要 requests 2.x，B 项目要 3.x，全装进系统 Python 里，最后两个项目互相打架，报错还查不出是谁的锅。解决办法只有一个——每个项目独立的虚拟环境，而且要从第一天就养成习惯。

第一条规则：一个项目一个 venv，绝不往系统 Python 里装包。用 `python -m venv .venv` 在项目根目录建环境，激活后 `pip` 装的所有包都只对这个项目可见。激活方式分平台：Linux/macOS 是 `source .venv/bin/activate`，Windows 是 `.venv\Scripts\activate`。判断自己有没有进环境很简单：看命令行前面有没有 `(.venv)` 前缀，或者跑 `which python`（Windows 用 `where python`），路径指向项目里的 .venv 才算数。退出用 `deactivate`。千万别图省事在系统 Python 里 `pip install`——系统自带的工具可能依赖那个 Python，一旦版本被改动，连系统工具都可能罢工。

第二条规则：依赖清单要分两层记。很多人只知道 `pip freeze > requirements.txt`，结果清单里混进了几十个间接依赖，换台机器重装时版本稍有漂移就装不上。更稳的做法是：手写一份 `requirements.in`，只列自己直接用到的包和版本范围，比如 `requests>=2.31,<3`、`pydantic>=2.0`；再用 `pip-compile`（pip-tools 提供）生成锁定的 `requirements.txt`，部署和复现都用锁定版。这样既知道项目真正依赖什么，出了兼容问题也容易定位到某一个包的升级。团队协作时把两份文件都进版本库，只把 .venv 目录排除掉——虚拟环境本身不需要、也不应该进 git。

第三条规则：换环境先验证，别凭感觉。新建环境后按顺序跑三步：`pip install -r requirements.txt` 装依赖，`python -c "import requests, pydantic; print('ok')"` 验证关键包能导入，最后跑一次项目的主入口或测试集。很多"在我机器上能跑"的问题，都是在第二步就露馅的：缺包、版本不对、某个包在新系统上编不过。定期还要做一次"干净重建"：删掉 .venv 重建一遍，确认 requirements.txt 真的能从零还原环境——这一步能提前发现那些"本地装过、清单里却没写"的隐性依赖。

三条规则总结起来就一句话：环境隔离、清单分层、重建验证。项目越小越要坚持，因为小项目最容易长大，而长大后再补依赖管理，成本是现在的十倍。