pip-compile 默认不严格锁定所有子依赖，因其设计目标是“语义版本兼容性优先”，仅保证直接依赖满足版本范围，而允许间接依赖随上游补丁自动更新以静默获取安全修复；如需完全可复现，须显式添加 --generate-hashes 和 --allow-unsafe，或在 requirements.in 中手动声明关键子依赖。
pip-compile 为什么默认不严格锁定所有子依赖？
因为 pip-compile 的设计目标是“语义版本兼容性优先”，不是“绝对不可变”。它只保证 requirements.in 中声明的直接依赖满足版本范围（如 requests>=2.28），而对间接依赖（如 urllib3、certifi）默认放行补丁更新——只要上游发个 requests==2.31.1，重跑 pip-compile 就会把 urllib3 从 1.26.15 升到 1.26.16。
这不是 bug，是特性：它让项目能静默获得安全补丁。但如果你需要完全可复现（比如金融/嵌入式场景），就得主动干预。
- 必须加
--generate-hashes，否则连包体完整性都不校验 - 仅靠
--generate-hashes还不够——它默认跳过 git/hg/svn 源，也拒绝锁 setuptools 等“unsafe”包 - 要真正全链锁定，得配合
--allow-unsafe（慎用，CI 中可能因工具链冲突失败） - 更稳妥的做法是在
requirements.in里显式写出关键子依赖，例如：urllib3==1.26.15
如何为 git 依赖生成带哈希的锁定行？
写成 mylib @ git+https://github.com/user/repo@v1.2.0 是不够的——pip-compile 默认忽略这类 URL 的哈希计算，CI 重装时可能拉到被 force-push 覆盖的 tag。
必须同时启用两个标志：
立即学习“Python免费学习笔记（深入）”；
-
--generate-hashes：触发对 git 源的 SHA256 计算 -
--allow-unsafe：解除对 VCS 源的默认屏蔽
但更推荐的做法是改用 commit hash：
mylib @ git+https://github.com/user/repo@e9a3f1c
这样即使 repo owner 强推 v1.2.0 tag，你的锁文件也不会失效。
pyproject.toml 里有 extras_require，怎么确保它被锁进 requirements.txt？
pip-compile 不会自动展开 setup.py 或 pyproject.toml 里的 extras_require。哪怕你写了 [project.optional-dependencies]，只要没在 requirements.in 里显式引用，就不会出现在最终锁文件中。
正确做法是：在独立的输入文件中声明，例如 requirements-dev.in：
-r requirements.in<br>fastapi[dev]<br>pytest>=7.0
然后运行：
pip-compile requirements-dev.in --output-file=requirements-dev.txt
注意：pip-tools >= 7.0 对 PEP 621 格式（即现代 pyproject.toml）解析更严格——如果 fastapi 的 pyproject.toml 没在 [project.dependencies] 里包含其 [dev] 依赖项，即使你写了 fastapi[dev]，也可能漏锁。
升级单个包却不扰动其余依赖，该用哪个参数？
--upgrade-package 是唯一可控的方式。比如只想升 django 到 4.2.x，但保留 djangorestframework==3.14.0 和所有其他间接依赖不变：
pip-compile --upgrade-package django requirements.in
它不会重跑整个依赖求解器，只局部更新 django 及其直系子依赖（如 sqlparse 若被新 django 强制要求更高版，仍会升——这是“保底不降级”的逻辑，不是 bug）。
对比 --upgrade：它会遍历整棵树找最新兼容版，大型项目可能卡住几十秒，且容易意外升到破坏性版本（比如把 pydantic 从 v1 升到 v2）。
真实风险点在于：很多人以为 --upgrade-package 是“精准手术刀”，却忽略了它无法阻止强约束引发的连锁升级——这点必须在 CI 前用 pip-compile --dry-run 预览变更。
