2023 年 10 月，Astral 发布了 uv 的首个版本。不到三年，这个用 Rust 写的 Python 包管理器拿下了 87.6k GitHub Stars，成为 Python 生态中最受关注的基础设施工具之一。

它不是 pip 的替代品——它是 pip、pip-tools、pipx、poetry、pyenv、virtualenv 的一体化替代方案。一个二进制文件，覆盖了 Python 项目从「装解释器」到「发包」的全生命周期。

为什么 uv 值 87k Stars

uv 最大的卖点只有一个字：快。官方基准测试显示，在 warm cache 场景下，uv 安装依赖的速度是 pip 的 10-100 倍。这个数字不是营销话术——你在终端里跑一次 uv sync 就能感受到差异。原因很简单：uv 用 Rust 实现，依赖解析算法（pubgrub）和包下载是并发的，而 pip 是串行的。

但快只是表面。uv 真正不可替代的地方在于它解决了一整套 Python 生态的碎片化问题：

一个二进制，替代一堆工具。 装 Python 用 uv python install 3.12，建虚拟环境用 uv venv，管理项目依赖用 uv add / uv sync，运行脚本用 uv run，发布包用 uv publish，锁 Python 版本用 .python-version。不需要再折腾 pyenv + poetry + pipx + virtualenv 的组合。四个工具变成一条命令，安装一次就够。

通用 lockfile。 Python 生态过去没有一个真正可靠的跨平台锁文件。poetry 的 poetry.lock 缺失平台信息，pip 的 requirements.txt 不锁传递依赖版本。uv 的 uv.lock 是跨平台的确定性锁文件——它在 macOS 上锁出来的依赖树和在 CI 的 Linux 上完全一致，因为 lockfile 里记录了每个包的 platform-specific marker。这个特性在微服务架构中特别关键：你的本地开发环境、CI 构建、生产容器可以共用同一个 lockfile，消除「在我机器上能跑」问题。

脚本直接跑，不用建虚拟环境。 Python 的 python3 script.py 默认使用系统 Python，跑之前必须手动 pip install。uv 支持 PEP 723 的 inline script metadata：你在脚本头部用注释声明依赖，uv run script.py 自动解析依赖、创建临时虚拟环境、运行、清理。这个过程是幂等的——同一个脚本在不同机器上跑出的依赖版本完全一致。

Rust 实现的 resolver 天生快。 uv 的依赖解析器 pubgrub-rs 是 Rust 实现，而 pip 用的是纯 Python。在依赖树很深的项目中（比如数据科学项目有 100+ 传递依赖），uv 的解析速度优势会放大到 100 倍以上。

白物集项目里的使用场景

我们在白物集管线中用 uv 替代了 pip 和 virtualenv，主要用在三个场景，每个都是真实的日常操作：

本地开发环境管理。 之前用 python3 -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt 这一套流程，每次切项目都要先激活环境。切到 uv 后，一条 uv sync 搞定——创建虚拟环境、解析依赖、安装，全部自动完成。实测从 12 秒降到了 1.2 秒左右。更重要的是，uv run 不需要手动激活虚拟环境，直接在项目目录里 uv run python main.py 就行。每天至少省下 20 次重复的 source .venv/bin/activate。

CI/CD 中的依赖安装。 白物集的 GitHub Actions 工作流之前跑 pip install -r requirements.txt 要等 40-60 秒。换成 uv pip install --system 后缩到 5-8 秒。对于每个 PR 都要跑一次的工作流来说，这个节省是实打实的——一个 10 次 commit 的 PR 能省下近 10 分钟的 CI 时间。

运行一次性脚本。 内容管线中有不少临时数据处理脚本（格式转换、图片处理、数据清洗）。以前需要手动创建虚拟环境、安装依赖、跑脚本、删除环境。现在直接在脚本头部声明依赖，uv run script.py 一次性执行。代码仓库里少了十几个零散的 requirements.txt。

比如这样一个数据清洗脚本，之前要三步：

python3 -m venv /tmp/clean-env
/tmp/clean-env/bin/pip install pyyaml httpx
/tmp/clean-env/bin/python3 clean.py

现在一步：

# /// script
# dependencies = ["pyyaml", "httpx"]
# ///
import yaml, httpx
# ... script body

uv run clean.py

uv 自动解析依赖、创建隔离环境、运行脚本，完成后自动清理。n = 3 个脚本切过来后，再也没有多出来的临时 requirements.txt 了。

需要留意的限制

uv 不是万能药，有几个场景不适合或者需要额外配置。

已有 poetry/pdm 项目的迁移成本。 uv 不完全兼容 poetry 的 lockfile 格式。迁移需要删除 poetry.lock、重新 uv lock 一次。如果项目已经用 poetry 稳定运行了两年，迁移收益不大——不坏就不修。

内网环境需要自建镜像。 uv 默认从 GitHub Releases 下载 Python 发行版，从 PyPI 下载包。如果公司在内网，需要配置 UV_PYTHON_INSTALL_MIRROR 和 PyPI 镜像。另外 uv 的 standalone installer 也是直连 astral.sh，内网需要换用 pip 安装或者预下载二进制包。

不管理 conda 包。 uv 只做 PyPI 生态，不管理 conda-forge 的包。如果你的项目混合使用 PyPI 和 conda（比如某些数据科学项目），uv 只能管 PyPI 那一半。Astral 在 roadmap 上提到 conda 支持，但短时间内还不是。

workspace 功能还不成熟。 uv 支持 monorepo workspace（类似 Cargo 的 workspace），在多包项目中表现不错，但 workspace 间的依赖重解析有时会导致 uv.lock 里出现重复条目。常见的做法是锁好之后用 uv tree 检查一次。

适合场景总结

• 新建 Python 项目——直接 uv init 生成标准项目结构，比手动建文件夹快得多
• 需要严格依赖锁定的项目——uv.lock 比 pip 的 requirements.txt 精确得多，支持 platform-specific markers
• 多 Python 版本切换——uv python install 3.12 相当于 pyenv 的一步替代，不用 brew install pyenv
• CI/CD 加速——对构建时间敏感的场景，uv 的 warm cache 表现极好，全缓存时安装 < 1 秒
• 频繁跑一次性 Python 脚本——inline script metadata（PEP 723）格式真的很方便

快速上手

# 1. 安装 uv（一行命令）
curl -LsSf https://astral.sh/uv/install.sh | sh

# 2. 初始化新项目
uv init my-project
cd my-project

# 3. 添加依赖
uv add requests httpx

# 4. 安装依赖并创建虚拟环境
uv sync

# 5. 运行脚本
uv run python main.py

如果要从已有项目迁移，uv pip install -r requirements.txt 可以当 pip 的即插即用替代——语法完全兼容，只是快 10 倍。等用熟了再切到 uv add 和 uv sync 的原生工作流。

一点思考

uv 的成功本身就是一个有意思的信号：Python 生态的工具链碎片化问题到了非解决不可的程度。Astral 用 Rust 写一个全能型工具，不是技术创新——依赖解析算法没有什么突破——而是产品设计创新。他们把「一站解决」做到了极致，让用户不需要在一堆工具文档之间反复横跳。

这也是为什么 87k 开发者愿意 star 一个包管理工具：基础设施工具不需要花哨，解决真实的痛感就够了。当你连续第二次因为 virtualenv 路径问题卡住的时候，就该试试 uv 了。