依赖地狱的本质是传递性版本约束无法同时满足。pip安装Flask时会递归解析其依赖树，当不同分支对同一包提出互斥版本要求（如click>=8.0与click<7.0），且元数据质量差、约束过严或全局环境混用时，便导致无解冲突。
依赖地狱的本质是传递性版本约束无法同时满足
当你执行 pip install flask，pip 不只装 Flask，还会递归安装它声明的 Werkzeug>=2.2.2、Jinja2>=3.0 等依赖；而这些依赖又各自带自己的依赖。最终形成一棵树，而非线性列表。一旦树中两个分支对同一包（比如 click）提出互斥要求——A 要求 click>=8.0,，B 要求 <code>click==7.1——pip 就无法选出一个能同时满足所有路径的版本，报错或静默降级（取决于 pip 版本和 resolver 模式）。
版本约束符号理解偏差会放大冲突概率
很多人把 ~= 和 ^ 当成“宽松兼容”，但它们行为不同且有陷阱：
-
~=1.2.3等价于>=1.2.3, ==1.*，允许1.2.4但拒绝1.3.0 -
^1.2.3（Poetry）等价于~=1.2.3；但^0.2.3却等价于>=0.2.3, ，因为主版本为 0 时语义不同 -
>=2.0看似宽松，但如果某库硬写requests==2.28.1，它就和>=2.30.0冲突——不是约束太严，而是有人锁死了
全局环境 + 直接 pip install 是冲突的温床
在没激活虚拟环境时运行 pip install，所有包都进系统 site-packages。这时：
- 项目 A 的
pyproject.toml写着django = "4.2"，项目 B 的requirements.txt写着django==3.2.20，但你只装过一次，两个项目实际共享同一个 Django -
pip freeze输出的是当前环境“快照”，不是项目“意图”；它不区分哪些是直接依赖、哪些是传递依赖，更不记录约束逻辑 - CI 流水线用
pip install -r requirements.txt，但本地开发时你手动pip install pytest过，导致环境不一致却难以察觉
现代 resolver 并非万能，尤其面对历史包
pip 自 2020 年起默认启用新 resolver，但它仍受限于上游元数据质量：
立即学习“Python免费学习笔记（深入）”；
- 某些老包的
setup.py里写死install_requires=['django==4.1.0']，连~=4.1.0都不肯用，根本没法解出兼容解 - PyPI 上 wheel 包的
requires_dist字段可能缺失或错误，导致 pip 误判依赖关系 - 当遇到
scipy==1.7.3（要求numpy>=1.16.5,）和 <code>onnx==1.13.1（要求numpy>=1.12.6）共存时，pip 只能选一个交集区间，而这个交集可能为空，或只剩一个极旧版本（如numpy==1.22.4），但该版本又不被其他新包支持
