Python依赖冲突的根源是多项目对同一库不同版本的需求，最可靠解法是环境隔离：用venv创建独立解释器与包空间，配合requirements.txt锁定精确版本，或用poetry统一管理依赖、环境与发布。
vendor 文件夹不是处理三方依赖冲突的终极手段——它压根就不该出现在现代 Python 项目里。
Python 没有官方 vendor 机制，也没有标准路径或工具支持把第三方包“打进”项目目录来绕过依赖管理。强行复制 pip install 下载的包进 vendor/，只会让问题更隐蔽、更难调试。
为什么 vendor 不解决依赖冲突，反而制造新问题
依赖冲突的本质是多个包对同一库提出互斥版本要求（比如 numpy>=1.20 和 numpy），而 Python 解释器在运行时只能加载一个 <code>numpy 版本。把不同版本的包手动塞进 vendor/ 并不能让它们共存——导入时仍会按 sys.path 顺序加载第一个匹配项，后装的覆盖前装的，行为不可控。
- 无法解决间接依赖：你 vendor 了
pandas，但它依赖的pytz、numpy还是得从 site-packages 加载，除非你也 vendor 所有传递依赖（这几乎不可能维护） -
import路径污染：一旦vendor/在sys.path前置，可能意外覆盖标准库或虚拟环境里的正确版本，引发AttributeError或ImportError - 部署时失效：CI/CD 流水线或容器镜像中若未同步
vendor/内容，或未修改PYTHONPATH，项目直接报错 - 与
pip工具链脱节：pip list、pipdeptree、pip freeze全部失效，你再也看不到真实依赖树
真正能落地的依赖隔离方案只有两个核心动作
所有靠谱的 Python 项目都基于这两步构建可重现环境：
- 用
python -m venv .venv创建干净虚拟环境，确保解释器和包空间完全独立 - 用
requirements.txt锁定精确版本（推荐加--no-deps导出 +pip install -r requirements.txt安装），而不是靠文件夹“搬运” - 如果项目较复杂，用
pip-tools管理requirements.in→ 编译生成带哈希的requirements.txt，避免手动维护版本号
什么情况下你会看到 vendor/？那是历史包袱，不是解法
极少数遗留项目或嵌入式场景（如某些 PyInstaller 打包流程、旧版 OpenStack 插件）曾用 vendor/ 避免系统级 pip 权限问题，但这属于权宜之计。2026 年的主流实践早已转向：venv + requirements.txt 或 poetry.lock，连 setup.py 都被 pyproject.toml 取代了。
真正容易被忽略的点是：哪怕你用了 venv，如果没激活就直接 pip install，或者在不同项目间复用同一个 .venv 目录，照样会冲突——隔离的前提是每次操作都在正确激活的环境下进行。
立即学习“Python免费学习笔记（深入）”；
