最典型依赖冲突：pip升级时旧版本被其他包硬依赖而无法卸载。可用--force-reinstall --no-deps、--use-deprecated=legacy-resolver排查；用pipdeptree查锁定源头；CI/CD锁全量版本，开发用pip-compile管理宽松约束。
pip install 报错 “Cannot uninstall ‘X’” 怎么办
这是最典型的依赖冲突现象：pip 尝试升级或重装某个包时，发现旧版本被其他已安装包硬性依赖，又没权限或策略去卸载它。pip 默认启用 --upgrade-strategy=only-if-needed，但很多场景下它判断“不需要卸载”，实际却卡死。
- 先运行
pip install --force-reinstall --no-deps绕过依赖检查，确认是不是纯卸载环节的问题包名 - 更稳妥的做法是加
--use-deprecated=legacy-resolver（pip 20.3+），切回旧版解析器，它对冲突的报错更直白、回退更可控 - 别用
sudo pip install硬怼——系统级 site-packages 权限混乱后，pip list和pip show显示的版本可能和实际 import 的不一致
怎么查清哪个包在偷偷锁死依赖版本
pip show 只显示单个包的 Requires，但真实约束来自整个依赖图。靠人眼翻容易漏掉传递依赖里的 pinned 版本。
- 用
pipdeptree --reverse --packages查谁依赖了它，尤其注意输出里带包名==或>=的那一行——那是强制锁定的源头 - 如果装的是本地
setup.py或pyproject.toml项目，检查install_requires或dependencies字段是否写了死版本，比如"requests==2.28.1" -
pip check能快速暴露已安装包之间的版本不兼容，但它不提示“该升谁”，只告诉你“有冲突”
requirements.txt 里写 == 还是 >=？
写死版本（==）看似安全，实则放大冲突概率；宽松约束（>=）又可能引入不兼容变更。关键不在符号本身，而在你控制依赖图的能力。
- CI/CD 流水线里必须用
==+pip freeze > requirements.txt锁全量版本，否则环境漂移无法复现 - 开发环境推荐用
pip-compile（来自pip-tools），它把in.txt里的>=解析成实际可安装的==，还能自动剔除未声明但被间接安装的包 - 别在
requirements.txt里混用-e git+https://...和==版本——前者会覆盖后者，pip install -r时顺序决定最终结果
virtualenv 里 pip 还冲突？可能是 Python 版本或架构不匹配
同一个 venv 下 pip 报冲突，有时根本不是包的问题，而是底层 ABI 或路径污染导致的“假冲突”。
立即学习“Python免费学习笔记（深入）”；
- 检查
which python和which pip是否指向同一 virtualenv 内的二进制，常见错误是激活了 venv 却用系统pip执行 - macOS 上 M1/M2 芯片用户容易遇到
arm64和universal2wheel 不兼容，pip debug --verbose里看compatible_tags是否包含当前平台 - Windows 用户如果用 conda 创建的 env，别混用
pip和conda install——它们的包数据库不互通，conda list看不到 pip 安装的包，反之亦然
真正难处理的不是报错信息本身，而是冲突发生在多层嵌套的 editable install + PEP 517 构建 + 自定义 pyproject.toml 配置里时，pip 的错误堆栈不会告诉你哪一行配置触发了约束传播。这时候得靠 pip install -v 滚动日志里找 “Conflicting dependencies” 开头的那几行，再结合 pipdeptree -w 对照看。
