如果你在 2026 年还只用 pip install 和一份手写的 requirements.txt 管理需要长期维护的项目，问题已经不在于"够不够用"，而在于你主动放弃了对可重现性的控制。Python 依赖管理长期被诟病为生态里的薄弱环节，但到 2026 年，规范面和工具面都已经足够成熟，选型的重点不再是"哪个工具更酷"，而是你的项目在依赖类型、速度、标准兼容性和团队惯性之间，究竟愿意付出什么代价。
一个有用的判断起点是看依赖的种类，而不是工具偏好：纯 PyPI 上的 Python 包是一类工作；需要本地编译或链接 C/C++ 库的二进制 wheel 是另一类；CUDA、GDAL、R 这类非 Python 系统软件是第三类。不同种类的工作，最优工具并不相同。
2026 年的底层共识：pyproject 与锁文件
在讨论具体工具之前，有一组事实已经基本成为共识。
pyproject.toml 是项目元数据的共同语言，[project] 表取代了历史上散落在 setup.py、setup.cfg 和各工具私有配置里的元数据。锁文件负责把"某一时刻解析出的全依赖图"固化下来，配合哈希让团队不再靠运气对齐环境。PEP 735 把 dev/test 等依赖分组写进了标准位置，PEP 751 则试图给锁文件一个共同方言 pylock.toml。
这意味着工具之间的差异，已经从"能不能做依赖管理"收敛到了解析速度、锁文件形态、标准遵循程度和 CI 足迹这几个可测量的维度上。选型就是对这几条轴做出优先级排序。
uv：把包管理变成"吞吐量问题"
uv 是 Astral 用 Rust 写的工具，官方定位是 "a single tool to replace pip, pip-tools, pipx, poetry, pyenv, twine, virtualenv, and more"，在纯 Python 依赖场景下比 pip 快 10 到 100 倍。一个典型的 Django 依赖树，CI 重建 venv 的时间可以从几十秒压到数秒。
但速度只是最显眼的层面。uv 真正的结构性优势在于它将"项目即环境"作为默认心智模型 ：uv init 一键初始化，自动管理 Python 版本，uv.lock 是跨平台锁文件，一条锁文件可以同时服务 macOS 本地开发和 Linux CI。uv 还提供了 pip 兼容接口，uv pip compile 和 uv pip sync 可以作为 pip-tools 的直接替代，迁移成本低。
到 2026 年，uv 仍在以极高的频率迭代（版本已进入 0.13.x），近期改进集中在锁文件的健壮性和解析性能上：语义等价的依赖声明会复用锁文件，冲突分组可以复用无元数据的锁文件，解析器在面对大量不可用版本时的处理也做了优化。这些改进本身不改变选型结论，但强化了 uv 作为"速度优先"选项的工程成熟度。
uv 的适用边界也很清晰：速度是主导约束、且依赖全部落在 PyPI 纯 Python 包或良好 wheel 上的场景 。但它不内置构建后端，发布 wheel 时需要搭配 hatchling 或 setuptools。对于深度绑定 Conda 生态的科学计算或 GPU 工作流，uv 不是原生答案------CUDA-linked PyTorch、GDAL 全栈、R 互操作这些场景，conda 家族仍然是更自然的起点。
Poetry：发布流水线的成熟度仍然是护城河
Poetry 是这些工具中生态最成熟的。它覆盖依赖解析、虚拟环境管理、构建和发布的全链路，poetry build 可以直接生成合规的 wheel 和 sdist 并推送到 PyPI 或私有仓库。对于需要发布到 PyPI 的开源库，或者依赖私有索引的企业内部包，Poetry 的 UX 至今仍然是最顺手的。
2025 年初的 2.0 版本是一个转折点：Poetry 将 PEP 621 的 [project] 表提升为首要元数据来源。2026 年 5 月发布的 2.4.0 引入了一个值得认真看待的特性：solver.min-release-age，即依赖"冷却期" 。你可以要求某个包的所有已知发行文件至少存在了若干天，才会被解析器纳入考虑，从而降低"上游包被投毒后几小时内就被装进 CI"的供应链风险。配套的 solver.min-release-age-exclude 和 -exclude-source 允许对内部包或私有索引放行。这是当前主流 Python 包管理器中少见的内置供应链时间缓冲机制。
Poetry 的代价同样明确：解析器是纯 Python 实现的，大型依赖树（尤其是涉及 torch 的场景）下解析可能需要数分钟，CI 冷缓存下的环境重建时间也显著高于 uv。它的锁文件是自定义 TOML 形态，与 PEP 621 的"标准对齐"程度不如 PDM 和 uv。
选 Poetry 的合理理由通常不是"它最好"，而是团队已经在用、发布流水线成熟，且锁文件抖动或解析速度没有构成实际交付瓶颈。在一个稳定运行的发布链路上，迁移的收益未必能覆盖切换成本。
PDM：标准原生的"安静中间项"
PDM 的定位在这些工具中最"安静"：它不做最激进的性能承诺，也不追求最全的功能覆盖，而是把对 PEP 标准的遵循做到最彻底 。原生 PEP 621 元数据、PEP 517 构建后端、PEP 735 依赖分组、插件系统和集中式安装缓存，都围绕"标准优先"来组织。锁文件是 pdm.lock（TOML），并且已经在导出和导入中处理 pylock 格式的互操作。
2026 年的 PDM 仍在持续打磨锁文件行为：2.27 允许通过 strategy.exclude-newer 配置默认的"排除过新版本"策略，2.28 引入了可选的锁输入新鲜度检查，2.29 则继续修正 PEP 735 依赖分组与可编辑安装之间的边界问题。这些变化的方向一致：不追求速度竞赛，而是把"锁文件作为唯一事实来源"这件事做稳。
PDM 的解析速度介于 Poetry 和 uv 之间，生态规模和 CI 集成成熟度弱于 Poetry。它的合理选型场景是：你想要一个 PEP 621 原生、锁文件稳定、不追求 uv 级速度，同时对构建后端保持自由选择权的管理器。
pip 与 pip-tools：标准地位仍在，治理状态在 2026 年已经明确
pip 仍然是 PyPI 的标准安装工具，随 Python 默认发行，在任何无法引入额外工具的环境里它都是底线方案。
pip-tools 在 2026 年经历了一个重要转折。维护它的 Jazzband 组织在 2026 年 3 月宣布日落，一度让 pip-tools 的长期治理变得不确定。但pip-tools 随后已经正式迁移到 PyPA（Python Packaging Authority），仓库和 issue tracker 都已转移到 PyPA 名下。这意味着它的长期维护风险比 2026 年早些时候的悲观判断要小。
不过，pip-tools 在功能层面的局限仍然存在：它至今不支持 PEP 735 依赖分组 ，锁文件形态仍然是 requirements.txt + 哈希，而不是 pyproject.toml 原生驱动的现代锁文件。对于一次性脚本、临时环境或无法引入外部工具的最小化场景，pip 和 pip-tools 仍然够用。但对于新项目，把 pip-tools 作为长期基础设施的吸引力正在下降------uv 的 pip 兼容接口提供了几乎无痛的升级路径，同时带来锁文件一致性和速度上的显著改善。
conda 家族：非 Python 依赖的不可替代选项
conda 在这个框架里的位置需要单独说清楚：它与其说是一个"更慢的 uv"，不如说是唯一能系统性解决非 Python 二进制依赖的工具族。CUDA toolkit、GDAL、HDF5、MKL 加速的 NumPy/SciPy、R 与 Python 共存，这些依赖无法被 PyPI wheel 可靠承载，而 conda channel（主要是 conda-forge）正是为它们准备的。在 CUDA-linked PyTorch、完整 GDAL 地理空间栈、R 互操作、从 Python 调用 ffmpeg 这些场景中，pip 和 uv 要么不可行，要么需要大量手工处理。
conda 的代价是体积和速度：环境动辄数 GB，原生 conda 的解析在大型 channel 上比 pip/uv 慢一个数量级。
conda 家族内部已经分化出两个重要的替代路径。mamba 使用与 conda 相同的包格式和 channel，但用 C++ solver 替代了原生解析器，通常快 5 到 10 倍，是现代 conda 工作流中事实上的解析层。pixi 则是更彻底的一步：Rust 编写，采用项目本地环境模型，用一条 pixi.lock 同时锁定 conda-forge 和 PyPI 依赖，PyPI 部分的解析直接调用 uv。它提供确定性的锁文件和任务运行器，在 conda 生态内同时解决了速度和可重现性两个问题。
一个被反复验证的实用模式是混合工作流：用 conda（或 pixi）搭建 native foundation，负责 CUDA toolkit 和系统库；然后在其中用 uv 管理上层的纯 Python 包。两者各司其职，不必强行让一个工具覆盖所有依赖类型。
按场景拆分的决策框架
把上述工具放回真实的工程约束中，选型可以收敛为几条清晰的路径。
新项目，纯 PyPI 依赖，速度敏感，CI 是日常瓶颈 ：选 uv。用 uv.lock 锁全依赖图，配合 hatchling 作为构建后端处理发布需求。这是 2026 年纯 Python 新项目的默认优选。
已有 Poetry 项目，发布流水线成熟，锁文件抖动可接受 ：留在 Poetry。如果供应链安全是关切，升级到 2.4+ 并配置 solver.min-release-age 是一条低成本的增强路径。
需要发布库，尤其是私有索引或多包发布：Poetry 的发布 UX 仍然最完整；如果同时想要 PEP 621 原生和更自由的构建后端选择，PDM 是合理替代。
CUDA、GDAL、R 互操作或非 Python 系统依赖：conda 家族是起点。存量环境可切换到 mamba；新项目且看重项目本地化和确定性锁文件，pixi 是更现代的入口。
标准合规是硬约束，且不需要 uv 级速度：PDM。PEP 621 原生、锁文件稳定、构建后端可选，是"标准优先"逻辑下最一致的选项。
遗留 pip-tools 工作流：pip-tools 已归入 PyPA，短期不必恐慌迁移；但新项目不建议再以它作为长期基础，uv 的 pip 兼容接口是更自然的升级方向。
对比表
| 维度 | conda / mamba / pixi | uv | Poetry | PDM | pip-tools |
|---|---|---|---|---|---|
| 核心定位 | 语言无关的二进制包与环境管理器 | 极速 Python 包与环境管理器 | 全链路 Python 发布工具 | PEP 标准原生的包管理器 | pip 生态内的锁文件方案 |
| 非 Python 依赖（CUDA/GDAL/R） | ✅ 原生支持 | ❌ | ❌ | ❌ | ❌ |
| 管理 Python 解释器 | ✅ | ✅ | ❌（需配合 pyenv） | ⚠️ 有限 | ❌ |
| 解析/安装速度 | 慢（原生 conda）；中（mamba）；快（pixi） | 最快（Rust，10--100× pip） | 慢（纯 Python solver） | 中 | 慢（继承 pip） |
| 锁文件形态 | environment.yml（conda）；pixi.lock（pixi，含 PyPI） |
uv.lock，跨平台 |
poetry.lock，自定义 TOML |
pdm.lock，TOML |
requirements.txt + 哈希 |
| PEP 621 原生元数据 | ❌ | ✅ | ✅（2.0+ 以 [project] 为主） |
✅ 原生优先 | ⚠️ 依赖 pyproject.toml 配置 |
| PEP 735 依赖分组 | ❌ | ✅ | ✅ | ✅ | ❌ |
| 供应链时间缓冲 | ⚠️ 依赖 channel 策略 | 部分支持 | ✅ solver.min-release-age（2.4+） |
⚠️ strategy.exclude-newer |
❌ |
| 构建与发布 | ❌（需配合其他工具） | ❌（需 hatchling 等后端） | ✅ 原生完整 | ✅（构建后端可选） | ❌ |
| 环境模型 | 全局命名环境（conda/mamba）；项目本地（pixi） | 项目本地 venv | 虚拟环境 | 虚拟环境 | 虚拟环境 |
| 典型体积开销 | 高（数 GB） | 低 | 中 | 中 | 低 |
| 治理状态（2026） | 成熟，conda-forge 生态稳固 | 快速迭代 | 成熟，2.4 新增供应链冷却 | 稳定，标准对齐持续 | 已从 Jazzband 迁移至 PyPA |
| 最适合的场景 | CUDA/GPU、GDAL、R 互操作、非 Python 二进制 | 纯 PyPI 新项目、CI 敏感 | 需要发布到 PyPI/私有索引的库 | 标准合规优先、构建后端自由 | 遗留工作流，不推荐新项目 |
一行结论 ：2026 年没有"唯一正确"的 Python 包管理器，但有一条清晰的决策主线------先看依赖里有没有非 Python 原生件。如果有，从 conda 家族（conda/mamba/pixi）出发，必要时叠加 uv 处理上层 Python 包；如果没有，uv 是速度优先的默认答案，Poetry 是发布成熟度的默认答案，PDM 是标准合规的默认答案，pip-tools 则是一个治理已归位、但功能代际上不再领先的存量选项。选型不是选边站，而是把你的工程约束翻译成工具的优先级。