虚拟环境里 pip install 成功，不代表已安装的包版本彼此兼容。遇到启动时才暴露依赖冲突，可以先跑：
python -m pip check
它会按当前解释器检查已安装包的依赖约束，直接列出缺什么或版本不满足。环境：Python 3.9+、pip。最好用项目实际启动命令对应的 python，别把系统 pip 和虚拟环境混了；这个命令只检查不改包，修完后再把锁文件或依赖声明一起更新。
这个命令适合放进 CI 的依赖检查步骤里，顺手看退出码就行：python -m pip check >/tmp/pip-check.txt && test ! -s /tmp/pip-check.txt。不过它只检查已安装发行版的依赖元数据，不会发现导入时的 ABI 或运行时配置问题；所以检查通过后，项目自己的最小启动/测试仍然要跑。
MukiLv1#1 这个命令适合放进 CI 的依赖检查步骤里，顺手看退出码就行：
python -m pip check >/tmp/pip-check.txt && test ! -s /tmp/pip-check.txt。不过它只检查已安装发行版的依赖元数据，不会发现导入时的 ABI 或运行时配置问题；所以检查通过后，项目自己的最小启动/测试仍然要跑。
还有个边界：它检查的是已安装发行版之间的依赖元数据，不会拿 requirements.txt 或锁文件逐项核对。CI 里可以把两件事分开：pip check 查环境里已经装出的冲突，再按锁文件重建环境跑一次最小导入测试，后者更能发现声明和实际环境对不上的问题。
雾很大Lv1#3 对，最好把
pip check当作环境层的一道信号。CI 里直接使用它的退出码会更稳，不要把“没有输出”当成成功条件；输出可以单独重定向留档，检查结果仍由命令本身决定。这样即使后面调整 pip 的输出格式，也不会误判。
再补一个容易忽略的边界：项目用了 extras 或环境标记时，pip check 只会按当前解释器里已安装发行版的元数据检查，不会替你验证每个可选 extra 在所有 Python/平台组合都能装通。CI 最好按支持的矩阵在干净环境里分别安装目标 extra，再跑 python -m pip check 和最小导入测试；这样能把依赖冲突和“某个平台才缺包”区分开。