pip check 报错如“requests 2.25.0 requires idna=2.5, but you have idna 3.1”表明依赖冲突：requests 强制要求 idna≥2.5且
pip check 能立刻告诉你当前环境里有没有包之间互相“打架”，但它不告诉你谁在打、为什么打、怎么停手——得配合其他命令一起用。
pip check 输出的错误信息到底在说什么
运行 pip check 后如果报错，典型输出像这样：requests 2.25.0 requires idna=2.5, but you have idna 3.1
这行话拆开看就是三件事：
- 上层包
requests==2.25.0明确要求idna版本必须满足=2.5（即 2.5 ≤ 版本 - 但你当前装的是
idna==3.1，超出了上限 - 冲突根源不在
requests本身，而在它依赖的idna和你手动/间接装的另一个版本撞上了
注意：pip check 不检查未安装的包，也不管你 requirements.txt 里写了啥——它只看「此刻已安装」的包之间是否自洽。
为什么 pip check 有时不报错，但 import 还是失败
常见于以下几种情况：
- 你用
pip install --force-reinstall强装了一个包，覆盖了原有依赖，但没触发重装其子依赖 - 多个包各自声明了对同一依赖的不同范围（比如 A 要
numpy>=1.21，B 要numpy），而你刚好装了 <code>1.23.5——pip check认为合法，但 B 的某段代码实际调用了 1.24 才引入的 API - 包通过
setup.py动态检测环境并修改依赖逻辑，pip check看不到这种运行时行为
换句话说：pip check 是静态兼容性快筛，不是运行时可靠性担保。
pip check 配合 pipdeptree 定位冲突源头
单靠 pip check 只能知道“有冲突”，但不知道哪个包把不兼容的依赖带进来的。这时候要接上 pipdeptree：
- 先装工具：
pip install pipdeptree - 查具体包的依赖路径：
pipdeptree --packages idna（把上面报错里的包名换进去） - 重点看输出里有没有类似这样的结构：
idna==3.1 ├── requests==2.25.0 [requires: idna=2.5] └── some-other-package==1.0.2 [requires: idna>=3.0]
这说明some-other-package是那个坚持要idna>=3.0的“钉子户”
如果你用的是 Poetry 或 Pipenv，对应命令分别是 poetry show --tree 和 pipenv graph，原理一样——找同名包被多个父级引用且版本不交叠的位置。
容易忽略的边界情况
这几个点不注意，pip check 就会给你假安心：
- 它默认不检查可选依赖（extras），比如
requests[security]里的cryptography冲突不会被扫到 - 虚拟环境隔离没做好：你在系统 Python 下跑
pip check，结果却去venv里跑代码，两个环境依赖完全独立 -
pip check对~=（兼容版本）和^（caret 版本，Poetry 专用）这类符号无感，只认最终解析出的已安装版本是否落在范围内 - 某些包用
pkg_resources或importlib.metadata延迟加载依赖，pip check根本看不到它们的约束声明
所以别让 pip check 成为唯一防线。CI 流程里加它，本地开发时把它和 pipdeptree 当成一对组合键——一个报警，一个查岗。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
