这不是bug，是pip≥21.3新解析器主动暴露依赖冲突：已装包版本互斥（如gradio需numpy~=1.0但已有2.2.6），表面安装成功却运行时报ImportError；应优先用虚拟环境隔离、pip-check验证、pip-tools生成锁文件，而非强制重装。
pip install 报 “dependency resolver does not currently take into account” 怎么办
这不是 pip 坏了，是它在明确告诉你：当前环境里已装的包互相打架，新解析器拒绝强行覆盖。它不报错退出，而是把冲突列出来，比如 gradio 4.21.0 requires numpy~=1.0, but you have numpy 2.2.6 —— 表面安装成功，运行时 import 就崩。
别急着加 --force-reinstall 或删包重装。先做三件事：
- 运行
pip check，看哪些包声明了互斥版本 - 用
pipdeptree --reverse --package numpy查谁在拉旧版numpy - 确认是否混用
conda和pip：如果conda list里有numpy，就别用pip install numpy==1.23.0强改，否则元数据会错乱
什么时候必须用 python -m pip 而不是直接敲 pip
只要出现 pip --version 和 python -c "import sys; print(sys.executable)" 输出路径不一致，就必须切到 python -m pip。Windows 上常见 C:\Users\X\Anaconda3\Scripts\pip.exe 指向 3.9，而你正用 3.11 运行脚本。
以下场景无条件用 python -m pip：
- 激活虚拟环境后，
pip list还显示系统包（说明 shell 找到的是 PATH 里的全局 pip） - CI/CD 脚本中，比如 GitHub Actions 的
run: pip install -r requirements.txt改成run: python -m pip install -r requirements.txt - 调用带空格路径的解释器时，整个路径要加引号：
"C:\Program Files\Python311\python.exe" -m pip install requests
requirements.txt 里依赖冲突，怎么生成可靠锁文件
pip freeze > requirements.txt 不解决问题，它只是快照，包含所有已装包（包括 dev 依赖、临时调试包），且不区分直接/传递依赖。真正能落地的是 pip-tools。
操作流程很轻量：
- 新建
requirements.in，只写你直接需要的包，例如：requests、flask>=2.3.0 - 运行
pip-compile requirements.in --output-file requirements.txt，它会递归求解所有约束，输出带哈希、精确版本、注释来源的锁文件 - 部署时用
pip-sync requirements.txt（比pip install -r更严格，会卸载不在列表里的包）
注意：pip-compile 默认不处理 --user 安装的包，也不读取 setup.py 里的 install_requires，所以顶层需求必须手动写进 .in 文件。
降级/升级某个包时容易踩的坑
直接 pip install package_name==2.28.2 看似简单，但可能触发连锁反应。比如降级 numpy 后，scipy 或 matplotlib 可能因 ABI 不兼容而 import 失败，错误信息却只报 ImportError: DLL load failed，不提 numpy。
更稳妥的做法是：
- 先查该包的
requires.txt：pip show package_name | grep Requires，或去 PyPI 页面看 “Requires” 字段 - 用
pip install --no-deps package_name==2.28.2跳过自动依赖，再单独验证每个依赖是否仍满足 - 如果项目允许，优先创建干净虚拟环境：
python -m venv fix-env && fix-env\Scripts\activate，再重装，而不是在污染环境中硬调
真正难的不是找不到兼容版本，而是你以为调好了，结果 import torch 时因为 protobuf 版本不对，底层 C++ 扩展加载失败——这种问题不会出现在 pip 日志里，得靠 strace（Linux）或 Process Monitor（Windows）才看得见。
