Python依赖解析需解决版本兼容性、传递依赖与平台约束，现代工具采用回溯式解析；推荐pip-tools分层管理（requirements.in+pip-compile生成带哈希的requirements.txt）或Poetry一体化处理，确保环境可复现与协作一致性。
理解依赖解析的本质
Python 的依赖解析不是简单地按顺序安装列表里的包，而是要解决版本兼容性、传递依赖和平台约束等实际问题。比如你装 requests==2.28.0，它会自动拉取兼容的 urllib3>=1.21.1, 和 charset-normalizer>=2.0.0；但若你同时手动指定 urllib3==1.25.2，而另一个包要求 urllib3>=1.26.0，pip 就会报冲突——这不是 pip “不行”，而是约束条件本身不可满足。
现代工具（如 pip 23.1+、pip-tools、poetry）默认启用回溯式解析器，能尝试不同版本组合来寻找可行解。但若你的 requirements.txt 写了过于宽泛的范围（如 django>=3.2）或混用 == 与 ~=，仍可能在不同机器上解析出不同结果。
用 pip-tools 锁定可复现的依赖
靠手写 requirements.txt 很难兼顾开发便利与部署稳定。推荐用 pip-tools 分层管理：
- requirements.in：只写直接依赖，例如：django~=4.2.0、psycopg2-binary
- 运行 pip-compile requirements.in 生成 requirements.txt：含所有传递依赖+精确版本+哈希校验
- 部署时用 pip install --require-hashes -r requirements.txt，确保每个包都来自预期源且未被篡改
这样既保留开发时升级主依赖的灵活性（改 .in 文件再重编译），又保证生产环境完全可复现。
立即学习“Python免费学习笔记（深入）”；
虚拟环境不是“隔离就够了”，关键在生命周期管理
创建虚拟环境只是起点。真正容易出错的是环境何时重建、如何同步、是否与项目绑定。
- 避免全局 venv 或随意命名的 env/ 目录：统一用 .venv（被多数编辑器和 gitignore 默认识别）
- 不手动激活再 pip install：用 python -m pip install -r requirements.txt 直接作用于当前 venv，避免误装到系统 Python
- 每次切换分支或更新依赖后，建议删掉旧 .venv 并重新创建+安装——看似费时，实则杜绝“残留包干扰行为”的隐性故障
Poetry：把依赖、环境、打包一体化处理
如果你希望一条命令管到底，Poetry 是更连贯的选择。它不替代 pip/virtualenv，而是封装并增强其工作流：
- poetry init 生成 pyproject.toml，声明依赖和元信息
- poetry install 自动创建专属虚拟环境、解析锁文件 poetry.lock、安装全部依赖（含 dev 组）
- poetry run python script.py 或 poetry shell 确保始终在正确环境中执行
- 发布时 poetry build 直接产出标准 wheel 和 sdist，无需额外配置 setup.py
它的锁机制比 pip-tools 更严格，默认锁定构建环境（Python 版本、平台标签），适合多团队协作或 CI/CD 流水线。
