依赖冲突：装个包装崩了项目，怎么排查和救回来

经典惨案：
复制代码
pip install 某个包
→ 它顺手把 numpy 从 1.24 降级到 1.19
→ 你的项目挂了
→ 你想把 numpy 升回去
→ 又挂了别的东西
折腾两小时，最后发现最省事的办法是重装环境。

这篇讲怎么快速判断"能不能救"和"要不要救"，以及怎么让它不再发生。

这张图怎么看 ：冲突的根源是两个包要求同一个依赖的不同版本------pip 会满足后装的那个，牺牲先装的。

读完这篇你能拿到：

① 三条命令快速定位 到底哪个包在搞事 ② 判断"救还是不救 "的标准（很多时候重装更快） ③ 一套让它不再发生的环境管理习惯

先说清楚：冲突的本质是什么

一句话版本：

两个包要求同一个第三方库的不同版本 ，而一个环境里同一个库只能有一个版本。

打个比方：合租

角色	对应
你	你的项目
室友	某个新装的包
空调温度	numpy 的版本

你要 26 度，室友要 20 度，空调只有一个 。最后谁后说话就听谁的------pip 处理冲突的逻辑基本就是这样：后来者赢，然后你就感冒了。

一、三条命令定位问题

① 先让工具帮你查有没有冲突

bash 复制代码

pip check

它会直接告诉你哪些包的依赖没被满足。这是最快的第一步------如果它干干净净，问题可能不在依赖冲突。

② 看某个包要求什么版本

bash 复制代码

pip show 包名

看 Requires 那一行，就知道它依赖哪些包、要求什么版本范围。

③ 看依赖树（最有用）

bash 复制代码

pip install pipdeptree
pipdeptree --packages numpy

它会列出谁依赖 numpy、各自要求什么版本。一眼就能看出是谁在拉低版本。

知道是谁搞的之后，你就有选择了：

换一个不冲突的版本装
或者干脆不用这个包
或者给它单独一个环境

二、救还是不救：一个判断标准

这张图怎么看：能不能一键重建，决定了该"慢慢修"还是"直接重装"。

值得慢慢修的情况：

环境里有装起来很麻烦的包（比如要编译的、要特殊驱动的）
你知道明确是谁冲突，改一个版本号就能解决
这个环境还要用很久

直接重装更快的情况：

你没有记录当初装了什么（没有 requirements.txt）
已经来回折腾好几轮了，越改越乱
这个环境本来就只是为了跑一次

一个很实在的经验 ：如果你没有 requirements.txt ，基本不用救了------因为你也不确定"修好"之后是不是和原来一样。重装 + 这次记得记录，比接着瞎试划算。

三、怎么救（值得救的时候）

办法一：指定版本安装

bash 复制代码

pip install numpy==1.24.3

装完立刻 pip check 看有没有引入新冲突。

办法二：让 pip 自己解决（新版 pip 更严格）

现在的 pip 有依赖冲突检查，装的时候如果会破坏现有环境，它会直接报错拒绝安装 ，而不是默默降级。这其实是好事------它拦住了你。

如果它报错，你可以选择：

换个版本装
用 --no-deps 只装这个包、不动依赖（有风险，要自己确认）

办法三：用 conda 的依赖求解

conda 的依赖求解比 pip 严格，装之前会把整个环境的依赖关系算一遍：

bash 复制代码

conda install 包名

代价是慢（求解可能要几分钟），好处是装完不太会莫名其妙崩。

办法四：实在不行就新建环境

bash 复制代码

conda create -n 新环境名 python=3.10
conda activate 新环境名
pip install -r requirements.txt

四、让它不再发生：四个习惯

这张图怎么看：前两条（隔离 + 记录）是最重要的，做到这两条就能避开大部分麻烦。

① 一个项目一个环境（最重要）

这是根治办法。项目 A 和项目 B 的依赖天然可能冲突，放一起迟早出事。

bash 复制代码

conda create -n projectA python=3.10
conda create -n projectB python=3.10

② 装完立刻记录

bash 复制代码

pip freeze > requirements.txt

把这个文件提交到 git。有了它，环境随时能重建，你就有底气说"大不了重装"。

用 conda 的话：

bash 复制代码

conda env export > environment.yml
conda env create -f environment.yml     # 重建

③ 装包前先看看它会动什么

新版 pip 会告诉你它会装/改哪些包，扫一眼再按回车。如果看到它要动 numpy、torch 这种核心包，就要警惕了。

④ 关键项目用容器

如果是要交给别人的、或者线上跑的项目，用 Docker 把环境固定下来。这是唯一能保证"我这儿能跑，你那儿也能跑"的方式。

五、什么时候该用 pip，什么时候该用 conda

这张图怎么看：同一个环境里尽量只用一种，混用是冲突的常见来源。

conda 更擅长：需要非 Python 依赖的包（比如 CUDA 相关的）、需要严格求解的场景
pip 更擅长：conda 源里没有的包、纯 Python 的包
别混着装 ：同一个环境里 pip 和 conda 交替装包是最容易出诡异问题的做法

如果不得不用 pip 装（conda 没有），先装 conda 的包，再用 pip 补，顺序反过来问题更多。

六、常见坑

这张图怎么看：第一个坑（在基础环境里装所有东西）是根源，它会让你没有退路。

① 所有项目都装在 base 环境里

等于把所有鸡蛋放一个篮子。一个项目崩，全部项目崩。一定要分环境。

② 没有 requirements.txt

没有记录就没有退路。装完顺手 freeze 一下，花三秒钟省两小时。

③ pip install --upgrade pip 顺手升级一切

别对整个环境做批量升级。要升就升具体的包，升完验证。

④ 复制别人的 requirements.txt 直接用

别人的环境里有他自己的版本组合，直接拿来装可能完全跑不起来 。更稳妥的是要 environment.yml（conda 导出，含完整锁定）。

⑤ 用 pip install -r 装完没验证

装完一定要跑一遍你的程序。装成功 ≠ 能用。

小结

冲突的本质：两个包要同一个依赖的不同版本，pip 通常让"后来者赢"
定位三件套：pip check → pip show → pipdeptree
没有 requirements.txt 就别救了，直接重装，这次记得记录
预防靠两条：一个项目一个环境 + 装完就 freeze
同一个环境里别 pip 和 conda 混着用

参考来源

pip 官方文档：依赖解析说明与 pip check 命令
conda 官方文档：环境管理与依赖求解说明
pipdeptree 官方项目文档