使用requirements.in管理依赖版本更精准

通过将顶层依赖声明与精确版本锁定分离，使用 requirements.in（人工维护、宽松约束）配合 pip-tools 自动生成带哈希的 requirements.txt（机器生成、严格锁定），Python 项目得以在开发、测试与生产环境中实现高度一致的依赖状态，从根本上杜绝“在我电脑上能跑”的兼容性灾难；这种分工明确的双文件策略不仅大幅降低手动维护子依赖的出错风险，还借助 pip-compile 的智能解析能力自动协调复杂依赖树，尤其在团队协作和频繁升级场景下，确保每次变更都经过完整依赖求解，而非凭经验硬编码版本——真正让依赖管理从玄学回归工程实践。

requirements.in 和 requirements.txt 的职责必须分开

不分离会导致每次改一个包都要手动更新所有子依赖版本，极易出错。requirements.in 只写顶层依赖（比如 requests、django>=4.2），不写任何具体版本号；requirements.txt 则是 pip-compile 自动生成的、带完整版本号和哈希值的锁定文件。前者人维护，后者机器生成——这是避免“在我电脑上能跑”问题的第一道防线。

pip-compile 解析依赖时需要宽松约束才能找到兼容解

如果你直接在 requirements.txt 里写死 django==4.2.0 和 requests==2.31.0，pip-compile 就没机会做版本协调。而 requirements.in 允许你用 ~=、>= 等操作符表达意图，例如：

django~=4.2
requests>=2.30

pip-compile 会基于当前 PyPI 状态、Python 版本、已有依赖组合，找出满足所有约束的最优版本集。这个过程没法靠人脑穷举，尤其当项目引入 sqlalchemy、pydantic 这类强依赖传递的库时。

多人协作中，requirements.in 是唯一该进 Git 的“需求说明书”

团队成员各自运行 pip-compile requirements.in，只要 Python 版本和 pip-tools 版本一致，生成的 requirements.txt 就该高度一致。但实际中常出现差异，原因包括：

• 本地缓存损坏 → 清掉 ~/.cache/pip-tools 再试
• 用了不同 Python minor 版本（如 3.11.8 vs 3.11.9）→ 要求 CI 和开发者统一使用 pyenv 或 asdf 管理
• requirements.in 里混入了 -e . 或本地路径 → 这类条目不会被 pip-compile 解析，应移出或用 --extra-index-url 配合

真正要提交到 Git 的只有 requirements.in 和生成的 requirements.txt；中间产物（比如编译日志、临时 .txt）不该进仓库。

升级某个包时，不能直接改 requirements.txt

直接编辑 requirements.txt 改版本号，等于绕过依赖解析器——下一次 pip-compile 运行时，它可能把你的手动修改覆盖掉，或者因为冲突而报 IncompatibleRequirements 错误。

正确做法是：

• 只改 requirements.in：比如把 requests 改成 requests>=2.32
• 加 --upgrade-package requests 参数重新编译：pip-compile --upgrade-package requests requirements.in
• 检查生成的 requirements.txt 是否包含预期变更，再提交

这一步漏掉，就等于把版本决策权从工具交还给人，而人容易忽略间接依赖的连锁反应。

最常被忽略的是：requirements.in 文件本身不校验语法，但一旦某行写成 requests == 2.31.0（带空格），pip-compile 会静默跳过这一行，导致最终环境缺包。务必用等号紧贴（requests==2.31.0）或完全不用版本号。

终于介绍完啦！小伙伴们，这篇关于《使用requirements.in管理依赖版本更精准》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！