很多 Python 项目真正的混乱，并不是从业务代码开始的，而是从环境和依赖开始的。解释器版本不同、包版本冲突、虚拟环境混用、依赖描述不完整，都会让一个项目变得难以复现、难以上手。
这一节我们会把虚拟环境、依赖安装、版本锁定、requirements.txt 和 pyproject.toml 的关系讲清楚，帮助你建立一套更现代、也更适合团队协作的依赖管理方式。
为什么依赖管理会影响项目寿命？
很多人第一次写 Python 项目时，习惯直接在全局环境里 pip install。短期看起来很快，但项目一多就会出现：
- A 项目需要某个旧版本依赖；
- B 项目又需要新版；
- 系统里到底装了什么、版本是什么，很难追踪；
- 换台机器就无法复现。
这意味着依赖管理问题本质上不是“装包方式问题”，而是项目是否可复现、可协作的问题。
一个项目写得再漂亮，如果别人拉下来跑不起来，它的可维护性也会大打折扣。
虚拟环境：venv 的使用方式
虚拟环境的核心价值，是把项目依赖隔离开来。
使用 venv 后，每个项目都可以拥有自己独立的一套第三方包，不会互相污染。
这意味着你在项目里安装 fastapi、sqlalchemy、pytest 时，实际上是在这个项目自己的环境里操作，而不是往系统 Python 里不断堆东西。
所以虚拟环境不应该被理解成“可选增强”，而应该被当成现代 Python 项目的默认基础设施。
pip 安装、升级与锁定版本
pip 是最基础的依赖安装工具，它解决的是“如何把第三方包装进当前环境”。
但真正重要的不是会不会执行安装命令，而是知道版本管理要有边界感。
例如：
- 某些核心依赖适合锁精确版本，确保稳定复现；
- 某些外围依赖可以接受一个范围，便于升级；
- 安装新依赖后，要及时同步依赖描述文件。
依赖版本一旦处于“本地装过但没记录”的状态，项目就已经埋下了后续复现困难的种子。
requirements.txt 与 pyproject.toml
两者的角色差异
requirements.txt 更像是“安装清单”，强调把某些包按特定版本装进环境。
而 pyproject.toml 则更像项目的统一配置入口。除了依赖声明，它还可以承载构建、格式化、Lint、测试等工具配置。
因此在现代 Python 项目里，pyproject.toml 的地位越来越重要。它让项目配置不再散落在一堆零碎文件里，而更集中、更统一。
你可以把两者简单理解成：
requirements.txt偏安装层和部署层；pyproject.toml偏项目描述层和工具协同层。
不同项目会根据团队习惯有所差异，但总体趋势是越来越多工程能力开始向 pyproject.toml 聚拢。
开发依赖与生产依赖如何划分？
并不是所有依赖都应该一股脑装进同一组里。
例如：
- Web 框架、数据库驱动属于运行时依赖；
pytest、ruff、mypy这类通常属于开发依赖。
把这两类依赖分开，有几个好处：
- 部署环境更干净；
- 依赖意图更清晰；
- 团队更容易理解哪些包是业务运行必须的，哪些只是开发阶段使用的。
所以依赖管理真正成熟的标志之一，不是文件里列了多少包，而是依赖有没有被按职责组织清楚。
总结与预告
这一节我们把 Python 项目最容易变乱的依赖管理问题做了系统梳理。一个项目是否容易复现、是否适合协作，往往首先取决于环境和依赖是否被好好管理，而不是代码本身写得多漂亮。
接下来我们会把依赖管理继续往前推进到质量保障层面，看看格式化、Lint、类型检查和提交前校验如何形成一套可靠的开发底线。