依赖冲突：装个包装崩了项目，怎么排查和救回来
经典惨案：
pip install 某个包 → 它顺手把 numpy 从 1.24 降级到 1.19 → 你的项目挂了 → 你想把 numpy 升回去 → 又挂了别的东西折腾两小时，最后发现最省事的办法是重装环境。
这篇讲怎么快速判断"能不能救"和"要不要救"，以及怎么让它不再发生。
这张图怎么看：冲突的根源是两个包要求同一个依赖的不同版本——pip 会满足后装的那个，牺牲先装的。
读完这篇你能拿到：
① 三条命令快速定位到底哪个包在搞事 ② 判断"救还是不救"的标准（很多时候重装更快） ③ 一套让它不再发生的环境管理习惯
先说清楚：冲突的本质是什么
一句话版本：
两个包要求同一个第三方库的不同版本，而一个环境里同一个库只能有一个版本。
打个比方：合租
| 角色 | 对应 |
|---|---|
| 你 | 你的项目 |
| 室友 | 某个新装的包 |
| 空调温度 | numpy 的版本 |
你要 26 度，室友要 20 度，空调只有一个。最后谁后说话就听谁的——pip 处理冲突的逻辑基本就是这样：后来者赢，然后你就感冒了。
一、三条命令定位问题
① 先让工具帮你查有没有冲突
pip check
它会直接告诉你哪些包的依赖没被满足。这是最快的第一步——如果它干干净净，问题可能不在依赖冲突。
② 看某个包要求什么版本
pip show 包名
看 Requires 那一行，就知道它依赖哪些包、要求什么版本范围。
③ 看依赖树（最有用）
pip install pipdeptree
pipdeptree --packages numpy
它会列出谁依赖 numpy、各自要求什么版本。一眼就能看出是谁在拉低版本。
知道是谁搞的之后，你就有选择了：
- 换一个不冲突的版本装
- 或者干脆不用这个包
- 或者给它单独一个环境
二、救还是不救：一个判断标准
这张图怎么看：能不能一键重建，决定了该"慢慢修"还是"直接重装"。
值得慢慢修的情况：
- 环境里有装起来很麻烦的包（比如要编译的、要特殊驱动的）
- 你知道明确是谁冲突，改一个版本号就能解决
- 这个环境还要用很久
直接重装更快的情况：
- 你没有记录当初装了什么（没有 requirements.txt）
- 已经来回折腾好几轮了，越改越乱
- 这个环境本来就只是为了跑一次
一个很实在的经验：如果你没有 requirements.txt，基本不用救了——因为你也不确定"修好"之后是不是和原来一样。重装 + 这次记得记录，比接着瞎试划算。
三、怎么救（值得救的时候）
办法一：指定版本安装
pip install numpy==1.24.3
装完立刻 pip check 看有没有引入新冲突。
办法二：让 pip 自己解决（新版 pip 更严格）
现在的 pip 有依赖冲突检查，装的时候如果会破坏现有环境，它会直接报错拒绝安装，而不是默默降级。这其实是好事——它拦住了你。
如果它报错，你可以选择：
- 换个版本装
- 用
--no-deps只装这个包、不动依赖（有风险，要自己确认）
办法三：用 conda 的依赖求解
conda 的依赖求解比 pip 严格，装之前会把整个环境的依赖关系算一遍：
conda install 包名
代价是慢（求解可能要几分钟），好处是装完不太会莫名其妙崩。
办法四：实在不行就新建环境
conda create -n 新环境名 python=3.10
conda activate 新环境名
pip install -r requirements.txt
四、让它不再发生：四个习惯
这张图怎么看：前两条（隔离 + 记录）是最重要的，做到这两条就能避开大部分麻烦。
① 一个项目一个环境（最重要）
这是根治办法。项目 A 和项目 B 的依赖天然可能冲突，放一起迟早出事。
conda create -n projectA python=3.10
conda create -n projectB python=3.10
② 装完立刻记录
pip freeze > requirements.txt
把这个文件提交到 git。有了它，环境随时能重建，你就有底气说"大不了重装"。
用 conda 的话：
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官方项目文档
