Poetry 与 pip‑tools 依赖锁定全对比解析

52JinY 助手

这几年折腾 Python 项目依赖管理，我在团队里反复切换过 Poetry 和 pip-tools，两套方案都能把环境“锁”住，但体验和哲学差异挺大，适用场景也不一样。这里把踩过的坑和爽点都摊开聊聊，给还在犹豫的同学一个现实向参考。

先说 Poetry。它主打“全家桶”：pyproject.toml 里声明依赖与元数据，poetry.lock 用于确定版本，

安装/发布/虚拟环境一条龙。优点是开发者心智负担小：poetry add requests 就能同时写入范围约束、解析依赖并更新锁文件；poetry install 落地到隔离环境，团队新人基本零配置就能跑起来。它的解析器偏保守，能较好避免“今天能装、明天炸库”的漂移；poetry export 还能导出 requirements.txt 供 CI 或容器镜像使用。缺点也明显：一是解析速度在复杂图上偏慢，monorepo 多子包时锁一次可能要好几分钟；二是封装太厚，出了问题要么读 verbose 日志、要么翻 issue，排障曲线比 pip-tools 陡；三是与一些“非标准”工作流掐架，比如公司内网私有索引的认证、源镜像切换、系统级包前置等，需要额外配置，踩错了容易出现 ResolutionImpossible。

再看 pip-tools（主要是 pip-compile / pip-sync）。它的思路是“薄而稳”：手写一个 requirements.in（或分层的 base/dev/prod.in），只写直接依赖与上界策略，通过 pip-compile 解析成带哈希的 requirements.txt，然后用 pip-sync 把环境精确对齐到锁定列表。优点在于透明可控：你能清楚看到每个依赖为何被锁，分环境文件也很自然；解析性能通常更快，且和原生 pip 强耦合，遇到装包问题时换源、加全局标志都顺手。缺点则是功能不自带：没有项目元数据、没有发布流程、也不管虚拟环境，你需要用 pyenv/venv/direnv/Makefile 自己拼；另外，团队自律要求高，忘了 pip-compile 或在 CI 里没用 pip-sync，就会出现“我这能跑你那不行”的小漂移。

团队协作层面，我更看重“可复制性 + 可见性”。Poetry 的 lock 文件天然满足复制性，但可见性一般，很多同学只用命令不看细节。pip-tools 的 diff 非常直观，review requirements.txt 的变更能一眼看出是哪个依赖引入了哪条子依赖，出了供应链安全公告时，定点升级也容易。另一方面，如果你需要发布库到 PyPI，Poetry 把 version、authors、classifiers、build-backend 全放在一处，加上 poetry publish 一气呵成，这点对“库作者”很友好；而应用型项目、尤其是容器化部署里，我更偏向 pip-tools：Dockerfile 用 pip install -r requirements.txt 可预测且启动快，镜像层缓存也更稳定。

说到可升级策略，Poetry 倾向语义化版本并在解析阶段保持解空间最小稳定解，偶尔会因为上游约束写得激进导致难以升级；pip-tools 则可以用 --upgrade-package 精确放开某个包，把其它都钉死，这对处理 CVE 或回滚事故很有用。跨平台一致性上，两者都建议把锁文件进库。Poetry 在不同平台生成的锁可能略有差异（可选依赖、平台标记），pip-tools 也一样，但 requirements.txt 更容易人工审查和拆分，比如给 manylinux 和 macOS 维护不同输出。

CI/CD 体验方面，Poetry 需要在流水线装 poetry 本体，export 再安装能提升速度；pip-tools 则可以在开发阶段编译好，把纯 requirements.txt 丢进仓库，CI 只做 pip install 和缓存 wheels，跑得更快。供应链合规里，pip-tools 的“带哈希锁定”默认就很严格；Poetry 也支持 hash，但落地到最终安装时常见做法还是 export 后交给 pip 执行，等于回到了同一条路径。

综合选择建议：
- 做“应用”，容器化部署、强调启动/构建速度与可见性：偏向 pip-tools，配合 make/ruff/pre-commit 把流程拼好，纪律性换来可控性。
- 做“库”，需要一体化元数据与发布：偏向 Poetry，享受统一配置与发布命令，配上 poetry export 兼容多场景。
- 做“多包/monorepo”，且需要统一发布：Poetry 的 workspace 能省心；如果更在意解析速度和分层锁定，pip-tools + per-package in 文件也能跑，但要多写脚本。

最后给两个实践小贴士：无论选谁，都尽量写上上界（