直接结论是必须分层控制：先隔离环境，再用pipdeptree定位真实冲突点，最后用pip-tools声明式收敛版本；pipdeptree --conflicts和--reverse可精准溯源间接依赖冲突，手动写死版本风险高，应依赖pip-compile自动求解兼容组合。
直接结论：这不是“选哪个版本”的问题，而是必须分层控制——先隔离环境，再定位冲突点，最后用声明式工具收敛版本。
用 pipdeptree 快速定位真实冲突点
很多人以为看 requirements.txt 就能发现冲突，其实不行。真正冲突常藏在子依赖里，比如 django 要 sqlparse>=0.4.4，而 psycopg2 却锁死在 sqlparse==0.4.2，这种间接冲突 pip install 日志里只报 “Cannot satisfy requirements”，不指名道姓。
- 装工具：
pip install pipdeptree - 查冲突：
pipdeptree --conflicts—— 只显示带[conflict]的行 - 反向溯源：
pipdeptree --reverse --package sqlparse看谁在拉这个包、各自要什么版本 - 别信
pip list：它只告诉你“现在装了啥”，不告诉你“谁要求装这个”
不要手动 pip install ==X.X.X 临时打补丁
显式写死 requests==2.28.1 到 requirements.txt 是最常见也最危险的做法。它可能让另一个依赖（比如 httpx）的 setup.py 中声明的 requires = ["requests>=2.29.0"] 直接失效，运行时报 AttributeError。
华为云 Python SDK 查询工具。自动发现已安装 SDK 的服务包、Client类、API 方法、入参详情、类信息（__init__ 参数、属性、类型、描述），支持关键字搜索，快速定位目标 API 使用方法。
- 优先升级间接依赖：比如冲突在
urllib3，先试pip install urllib3>=2.0.0，再看pip check是否通过 - 降级要查变更日志：
requests从 2.28 → 2.29 删除了.json()的verify参数，硬降可能引发运行时错误 - 跳过自动依赖再手动装：
pip install mypackage --no-deps，然后单独装兼容组合
用 pip-tools 实现声明式依赖收敛
靠人脑算兼容版本是不可持续的。pip-compile 的作用不是“生成一个 txt”，而是把“我想要什么”和“实际能装什么”解耦，让工具替你遍历所有组合并选最优解。
- 只在
requirements.in写顶层依赖：django~=4.2.0、requests>=2.25.0 - 运行：
pip-compile --generate-hashes requirements.in→ 输出带哈希和全依赖树的requirements.txt - 部署时只认
requirements.txt：pip install -r requirements.txt，不走任何解析逻辑 - 升级某包？改
requirements.in后重跑pip-compile，它会自动调低certifi或升高等其他依赖来保兼容
虚拟环境不是可选项，是执行前提
所有上述操作都默认你在干净虚拟环境中进行。如果还在全局 pip 或混用 conda 和 venv，pipdeptree 查出来的结果根本不可信——它看到的是整个系统叠加后的混乱状态。
- 每个项目根目录执行：
python -m venv .venv - 激活后第一件事：
pip install --upgrade pip（旧 pip 解析器有 bug） -
.venv/必须加进.gitignore；但requirements.txt和pyproject.toml必须提交 - CI 流水线里也要用同样命令建环境，否则本地能跑、CI 报错就是环境没对齐
最容易被忽略的其实是“冲突是否真存在”：有些报错看着像版本冲突，其实是 __init__.py 缺失、C 扩展没编译、或 PATH 指向了旧 Python。动手前先确认 which python 和 python -c "import sys; print(sys.path)"，比瞎调版本有用得多。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
