Python依赖冲突的根源在于多项目对同一库不同版本的需求，最可靠解法是环境隔离：用venv创建独立解释器与包空间，配合requirements.txt锁定精确版本，或用poetry统一管理依赖、环境与发布。
Python依赖冲突本质是不同项目需要同一库的不同版本，而全局安装环境无法同时满足。最可靠解法不是强行降级或升级，而是从源头隔离——让每个项目拥有独立的Python解释器和包空间。
用venv创建轻量级隔离环境
Python 3.3+ 自带 venv 模块，无需额外安装工具。它复制一份精简的Python解释器，并在项目目录下建立独立的 site-packages 文件夹，所有 pip 安装的包只对当前环境生效。
- 进入项目根目录，运行：python -m venv .venv（生成名为 .venv 的文件夹）
- 激活环境：source .venv/bin/activate（macOS/Linux）或 .\.venv\Scripts\activate（Windows）
- 激活后命令行前缀会显示 (.venv)，此时 pip list 只显示空环境或你手动安装的包
- pip install -r requirements.txt 将严格按当前文件安装，不干扰系统或其他项目
用requirements.txt锁定精确版本
仅靠环境隔离还不够——若多人协作或部署时未固定版本，仍可能因 pip 自动升级导致行为差异。必须明确声明每个依赖的完整版本号（包括次版本和修订号）。
- 生成当前环境完整快照：pip freeze > requirements.txt
- 避免使用 pip install package（默认装最新版），改用 pip install package==2.1.0
- 可借助 pip-tools：写 requirements.in（如 requests>=2.25），再运行 pip-compile 生成带哈希值的 requirements.txt，兼顾灵活性与可重现性
用poetry统一管理依赖与环境
当项目依赖复杂（含开发依赖、可选依赖、私有源），或需发布为包时，poetry 提供更结构化方案：它自动创建虚拟环境、解析依赖树、生成锁文件（poetry.lock），并支持一键打包与发布。
- 初始化项目：poetry init（交互式填写元信息）
- 添加依赖：poetry add requests@^2.28.0（自动处理兼容性并写入 pyproject.toml）
- 安装全部依赖：poetry install（读取 lock 文件，确保所有人装完全相同版本）
- 进入环境 shell：poetry shell，或直接运行：poetry run python script.py
避免常见误区
环境隔离不是万能胶，错误操作仍会导致冲突重现。
- 不要在激活虚拟环境后执行 pip install -U pip —— 升级 pip 本身可能引发后续安装逻辑变化
- 不要把虚拟环境文件夹（如 .venv）提交到 Git —— 应加入 .gitignore，只提交 requirements.txt 或 pyproject.toml
- 不要混用 pip 和 conda 管理同一环境 —— 二者包索引与二进制兼容性不同，极易引发 ABI 冲突
- CI/CD 中务必显式指定 Python 版本（如 GitHub Actions 的 python-version: '3.11'），避免因默认版本漂移引入隐性不一致
