有时安装过程没报错，运行项目才发现依赖版本对不上。可以在当前虚拟环境里先跑：
python -m pip check
它会检查已安装包的依赖是否满足；没有问题时会输出 No broken requirements found.，发现冲突则会列出缺哪个版本。
这个命令只检查环境，不会修改包。比如刚执行完 pip install -r requirements.txt，或者切换了一批依赖后，顺手跑一下很省时间。注意要确认 python 指向的是项目正在使用的那个虚拟环境。
这个还挺适合放在 CI 的依赖安装后面，成本很低。
如果项目有 requirements.txt、requirements-dev.txt 或不同 extras，最好在各自会实际运行的环境里都跑一次：
python -m pip install -r requirements.txt
python -m pip check
它查的是当前环境里已经装好的包，所以虚拟环境没切对时结果也会跟着跑偏。
还有个小坑：pip check 看的是当前环境里已经安装出来的结果，不会帮你判断某个约束文件未来能不能解开。
所以我一般会把它放在安装之后，当成最后一道验收：
python -m pip install -r requirements.txt
python -m pip check
python -m pip freeze > installed.txt
如果前面解析阶段就想先看会装什么，还是得配合 pip install --dry-run --report ... 这类方式。两者检查的阶段不太一样。
再补个边界：pip check 只看已安装包声明的依赖关系，不能替代导入或启动测试。比如依赖元数据都满足，但包文件损坏、平台二进制不匹配，或者配置缺失，它可能仍然通过。放在安装后做快速验收很好，后面最好再接项目最小启动/测试。
还有一种场景也适合跑：本地临时装了一个工具包，后来忘了卸，环境里可能会留下和项目无关的依赖。pip check 如果报冲突，第一眼别只盯着 requirements，也可以顺手看下：
python -m pip list --not-required
不一定马上删，但能帮忙判断是不是环境被别的包污染了。长期看还是重建虚拟环境最干净。
Nathan03Lv1#5 还有一种场景也适合跑：本地临时装了一个工具包，后来忘了卸，环境里可能会留下和项目无关的依赖。
pip check如果报冲突，第一眼别只盯着 requirements，也可以顺手看下：python -m pip list --not-required不一定马上删，但能帮忙判断是不是环境被别的包污染了。长期看还是重建虚拟环境最干净。
pip list --not-required 这个线索挺实用，不过它更像候选清单，不等于这些包一定没用了。项目代码直接 import 的顶层包、启动脚本或额外功能用到的包，也可能不会被别的已安装包声明依赖。准备清理时我会再对照 requirements/项目配置，并在临时环境里跑一下最小启动。