编程 uv 深度实战：一个 Rust 二进制如何吞掉整个 Python 工具链——从全局缓存、统一锁文件到 Workspace 单体仓库的生产级完整指南（2026）

2026-07-20 03:44:45 +0800 CST views 20

uv 深度实战：一个 Rust 二进制如何吞掉整个 Python 工具链——从全局缓存、统一锁文件到 Workspace 单体仓库的生产级完整指南（2026）

如果你 2026 年还在用 python -m venv + pip install + pip-tools + poetry + pyenv + pipx 这套七件套管理 Python 项目，那么这篇文章就是写给你的。本文不堆砌参数表，而是从工程实践视角，把 uv 为什么快、快在哪、以及它真正改变的是什么讲透，并给出可落地的生产级配置。

一、背景介绍：Python 依赖管理的"巴别塔"

任何一个在 Python 圈混过三年以上的工程师，都欠依赖管理一笔"精神损失费"。这不是你的问题，是生态的问题。

1.1 一套习以为常、实则荒诞的工具链

一个中等规模的后端服务，落地一套"标准" Python 环境，通常需要这些工具各自为政：

virtualenv / python -m venv：创建隔离环境。问题是它只隔离，不管理依赖来源。
pip：安装包。慢、顺序解析、没有真正的锁文件概念（pip freeze 只是把已装版本拍平，丢失了约束来源）。
pip-tools（pip-compile / pip-sync）：补上"约束 + 锁文件"的缺口，但 requirements.in → requirements.txt 两套文件，心智负担翻倍。
poetry：把依赖和构建合在一起，有 pyproject.toml 和 poetry.lock。但它自己实现了一套 resolver，版本迭代期 resolver 经常卡死，且和 pip 生态的某些 wheel 行为不完全一致。
pyenv：管 Python 解释器版本。但它和项目环境是分离的，CI 里经常"本地 3.11、CI 3.10"对不上。
pipx：专门装命令行工具（ruff、black、httpie）。又是一个独立心智模型。
twine：发包到 PyPI。又一个独立工具。
conda / mamba：科学计算栈的救命稻草，但和 PyPI 生态是两套宇宙，环境动辄几个 GB。

你没看错——为了"把一个项目的依赖装对"，一个工程师的肌肉记忆里要塞进 7 个以上工具、5 种以上的配置文件格式。更荒谬的是，这 7 个工具之间几乎不共享状态：pyenv 装好的解释器，poetry 不一定认；pipx 装的工具，pip 看不见；pip-tools 的锁文件，poetry 不认。

1.2 痛点的工程后果

这种碎片化在生产环境里被放大成三类具体事故：

可复现性崩坏：pip install -r requirements.txt 在不同时间跑，结果可能不同（上游发了新补丁版本）。requirements.txt 里写 requests>=2.0 和写 requests==2.31.0 是两回事，而手写精确版本号又牺牲了安全更新。
CI 慢到离谱：每次 CI 从头 pip install，几百个包顺序下载编译，5~15 分钟是常态。缓存？pip 的缓存是 per-machine 的，且对源码包（sdist）的构建结果不共享。
新人第一天在配环境：clone 下来 → 配 pyenv → 切 Python → 建 venv → 装 poetry → poetry install → 发现 resolver 冲突 → 查 issue。一天没了。

1.3 uv 的出现：不是"更快的 pip"，是"更少的工具"

2024 年初，Ruff（那个用 Rust 重写的 Python linter，把 flake8 快了 10~100 倍）的作者 Astral，发布了 uv。官网一句话定位：

An extremely fast Python package and project manager, written in Rust.

但它的野心远不止"快"。uv 的官方 Highlights 里写得很清楚——一个工具，替代 pip、pip-tools、pipx、poetry、pyenv、twine、virtualenv。注意是"替代"（replace），不是"包装"。这意味着 uv 不是在这些工具外面套壳，而是用 Rust 从零实现了一套统一的依赖管理内核，把这 7 个工具的职能收编进同一个二进制、同一套心智模型。

本文的核心论点正是：uv 真正的创新不是 10~100 倍的速度（虽然这是最容易被记住的卖点），而是它把"解释器管理 + 虚拟环境 + 依赖解析 + 锁文件 + 工具安装 + 脚本运行 + 发包"收敛成了一个有内聚设计的可复现系统。速度只是这个统一设计顺带的结果。

二、核心概念：一个二进制，五种人格

理解 uv 最好的方式，是把它当成"披着单一 CLI 外衣的五个工具"。每个子命令对应过去一套独立工具，但共享同一个全局缓存和同一个 resolver。

2.1 人格一：pip 的替身（`uv pip`）

uv pip 是 pip 的 drop-in 替代品。你几乎可以把 pip 全局替换成 uv pip 而工作流不变：

# 传统 pip
pip install requests
pip install -r requirements.txt
pip freeze > requirements.lock

# uv 等价物，速度快一个数量级
uv pip install requests
uv pip install -r requirements.txt
uv pip freeze > requirements.lock

但它的价值不止"快"。uv pip compile 能把 requirements.in 编译成带哈希、跨平台的锁文件，而且支持 pip 没有的高级能力：依赖版本覆盖（override）、平台无关解析、可复现解析、可选解析策略。

2.2 人格二：项目管理器（`uv init` / `uv add` / `uv sync`）

这是 uv 的"现代模式"，对标 poetry / rye。一条命令从零到可运行：

uv init my-api        # 创建项目骨架
cd my-api
uv add "fastapi>=0.110"   # 加依赖，自动建 .venv、写 pyproject、更新 uv.lock、安装
uv add --dev pytest ruff  # 开发依赖进 dependency-groups.dev
uv run fastapi dev main.py  # 在隔离环境里跑命令
uv sync               # 按 uv.lock 精确同步环境

注意这里发生了四件事，过去需要四个工具配合：uv add 同时改了 pyproject.toml、生成/更新 uv.lock、创建 .venv、把包装进环境。uv run 则在保证环境就绪后才执行命令——没有"忘了激活 venv"这种事。

2.3 人格三：Python 版本管理器（`uv python`）

uv python install 直接从 Astral 维护的 python-build-standalone（基于 indygreg 的构建）下载预编译的 CPython，无需系统包管理器、无需 pyenv：

uv python install 3.10 3.11 3.12 3.13   # 一批装好
uv python pin 3.12                       # 给当前项目钉版本，写入 .python-version
uv python list                           # 看本机所有 uv 管理的解释器
uv venv --python 3.12                    # 用指定版本建 venv
uv run --python 3.13 -- python -c "import sys; print(sys.version)"

关键点：Python 解释器本身成了"可下载的 artifact"，和操作系统解耦。这在 Docker 和 CI 里是质变——你再也不用 apt-get install python3.12 然后祈祷源里有。

2.4 人格四：命令行工具运行器（`uvx` / `uv tool`）

对标 pipx。uvx 是 uv tool run 的别名，能在一次性隔离环境里跑任何 Python CLI，用完即弃：

uvx ruff check .          # 不污染项目环境，秒级拉起 ruff
uvx --with rich cowsay "hi"
uv tool install ruff      # 持久安装，进 ~/.local/bin
uv tool upgrade ruff      # 升级
uv tool list              # 列出已装工具

2.5 人格五：单文件脚本运行器（PEP 723）

这是很多老 Python 用户忽略的杀手锏。借助 PEP 723 内联元数据，单个 .py 文件可以自带依赖声明，uv run 会为它造一个临时环境：

# /// script
# requires-python = ">=3.11"
# dependencies = ["requests", "rich"]
# ///
import requests
from rich import print

resp = requests.get("https://api.github.com/rate_limit")
print(f"[green]剩余额度:[/green] {resp.json()['rate']['remaining']}")

uv run report.py     # 自动创建临时 venv、装 requests+rich、运行，结束回收

一个脚本 = 一个自包含的可复现单元，不再需要为"就三行的小工具"专门建项目。

三、架构分析：uv 为什么能既快又准

要写出生产级配置，得先懂它底层怎么动。uv 的架构可以拆成五块：Rust 内核 + PubGrub 解析器 + 内容寻址全局缓存 + python-build-standalone + 统一锁文件格式。

3.1 Rust 内核与并行

uv 用 Rust 写成，依赖下载、wheel 解包、环境装配都是并行 + 异步的。pyproject 解析用 toml crate，版本比较用 pep440_rs（Rust 实现的 PEP 440 版本规范）。对比纯 Python 的 pip/poetry，光是"解析版本字符串"这一步，Rust 就快了几个数量级，更别说锁文件里几百个包的版本比较是 O(n) 遍历。

3.2 PubGrub 解析器：为什么 uv 很少"死锁"

pip 的解析器是"贪心 + 回溯有限"，复杂依赖图下容易卡住或给出错误结论。poetry 早期自研 resolver，遇到冲突经常抛"无法解析"且不告诉你根因。uv 用的是业界公认的 PubGrub 算法（和 Cargo、Dart 同款），它的核心优势是失败即解释：当依赖冲突时，uv 会告诉你"因为 A 要求 flask<3，而 B 要求 flask>=3，所以无解"，而不是一团栈跟踪。

$ uv add "flask<3" "some-pkg-that-needs-flask>=3"
  × No solution found when resolving dependencies:
  │  because flask<3 and some-pkg requires flask>=3, ...
  └  flask<3 and flask>=3 are incompatible

这种"可解释的无解"在工程里价值巨大：你不用再盲猜是哪个包在作妖。

3.3 内容寻址全局缓存：速度的真正秘密

pip 慢，一半慢在"每次都重新下载、重新编译"。uv 在 ~/.cache/uv 维护一个内容寻址（content-addressable）的全局缓存：每个 wheel / sdist / 构建产物按内容哈希存一份，全项目、全环境共享。

更关键的是安装方式：uv sync 默认用 hardlink（硬链接） 把包从全局缓存"链接"进 .venv，而不是复制。这意味着：

第 1 个项目装了 numpy，占 200MB 缓存；
第 2、第 10、第 100 个项目装 numpy，磁盘上几乎零额外占用（只是多个硬链接）；
CI 里只要缓存目录在，装环境基本是"建链接"的速度（毫秒级）。

你可以用环境变量微调链接策略：

export UV_LINK_MODE=hardlink   # 默认（Linux/macOS）；最省空间
export UV_LINK_MODE=copy       # 跨文件系统 / 需要独立修改时用
export UV_LINK_MODE=symlink    # 某些只读场景
export UV_CACHE_DIR=/mnt/fast-ssd/uv-cache   # 把缓存挪到高速盘

实战经验：在 CI 里缓存 UV_CACHE_DIR 而非 .venv，是"复用"与"可复现"之间最稳的平衡点。.venv 是派生产物，缓存它容易在 runner 漂移时拿到脏环境；缓存 UV_CACHE_DIR 则每次都从锁文件重建 .venv，既快又干净。

3.4 python-build-standalone：把解释器变成 artifact

uv python install 下载的不是系统 Python，而是 python-build-standalone——由 Astral 维护的、静态链接了 OpenSSL 等依赖、可随处运行的 CPython 构建。好处：

不依赖系统 libpython、openssl 版本；
同一份构建在 CI、本地、Docker 里字节一致；
多版本共存零冲突，uv python list 一眼看全。

这等于把"Python 版本"从"操作系统状态"降级成了"项目配置"——和 Node 的 nvm、Rust 的 rustup 一个哲学。

3.5 统一锁文件：平台无关解析 + 平台相关产物

uv.lock 是 uv 最被低估的设计。它是一份 TOML 格式的"通用锁文件"：

解析是平台无关的：锁文件记录的是"约束层面的解"（每个包选了哪个版本、为什么），而不是"某个 OS 的某个 wheel"。
产物是平台相关的：真正安装时，uv 根据当前平台从锁文件里挑对应的 wheel（macOS arm64 / linux x86_64 / windows…），缺失则现场构建。

这意味着同一份 uv.lock 在 macOS 开发机、Linux CI、Windows 笔记本上都能精确复现，不会出现"我这儿能跑你那儿装不上"。对比之下，pip freeze 吐出的是当前平台的精确版本+哈希，换平台直接失效；poetry.lock 虽好，但生态兼容性和解析器稳定性长期被诟病。

uv.lock 还内建了来源证明（source tree）——你能看到每个包是从 PyPI 还是私有源拉的，配合 uv export 还能导出成 requirements.txt 给不迁移 uv 的下游用：

uv export --format requirements-txt --output-file requirements.lock.txt
uv export --format requirements-txt --no-hashes --extra dev   # 给传统 pip 用

四、代码实战：从零搭一个生产级 uv 项目

光讲概念没意思。下面用一个真实的后端服务骨架，演示 uv 在产线的完整用法。

4.1 初始化与依赖分层

uv init --package my-api          # --package 表示这是个可发布的库/服务
cd my-api
uv add "fastapi>=0.110" "uvicorn[standard]>=0.30" "pydantic>=2.7" "sqlalchemy>=2.0"
uv add --dev pytest pytest-asyncio ruff mypy
uv add --optional redis "redis>=5.0"   # 可选依赖组 redis

生成的 pyproject.toml 长这样（节选）：

[project]
name = "my-api"
version = "0.1.0"
requires-python = ">=3.11"
dependencies = [
    "fastapi>=0.110",
    "uvicorn[standard]>=0.30",
    "pydantic>=2.7",
    "sqlalchemy>=2.0",
]

[project.optional-dependencies]
redis = ["redis>=5.0"]

[dependency-groups]
dev = [
    "pytest>=8.0",
    "pytest-asyncio>=0.23",
    "ruff>=0.5",
    "mypy>=1.10",
]

[tool.uv]
dev-dependencies = []   # 旧式写法，新项目用 dependency-groups

关键点：生产依赖进 [project].dependencies，开发依赖进 [dependency-groups].dev，特性开关进 [project].optional-dependencies。三者安装范围不同：

uv sync：只装生产依赖（部署用）；
uv sync --dev：生产 + dev 组（本地开发用）；
uv sync --extra redis：生产 + redis 可选组（需要缓存的部署用）；
uv sync --all-extras --dev：全要（CI 测试矩阵用）。

这种"分组即环境"的模型，比 requirements-dev.txt + requirements.txt 双文件清晰得多，而且由锁文件保证一致。

4.2 读懂 uv.lock：把依赖图当成一等公民

uv tree 能可视化依赖树，排障时比翻 pip show 高效：

uv tree
# my-api v0.1.0
# ├── fastapi v0.111.0
# │   ├── starlette v0.37.2
# │   │   └── anyio v4.4.0
# │   └── pydantic v2.8.2
# └── sqlalchemy v2.0.31

uv.lock 里每个包都有 name、version、source、dependencies 字段，且带环境标记：

[[package]]
name = "anyio"
version = "4.4.0"
source = { registry = "https://pypi.org/simple" }
dependencies = [
    { name = "idna" },
    { name = "sniffio" },
    { name = "exceptiongroup", marker = "python_full_version < '3.11'" },
]

看到 marker = "python_full_version < '3.11'" 了吗？这就是"平台无关解析、平台相关装配"的体现——锁文件里预存了所有平台的约束，安装时按本机解释器版本筛选。

4.3 PEP 723 脚本：让运维小工具自包含

产线常有一堆"三行脚本"：查队列长度、dump 慢查询、清缓存。过去这些要么塞进大项目，要么散落各处版本不明。用 PEP 723，一个文件搞定：

# /// script
# requires-python = ">=3.11"
# dependencies = ["redis>=5.0", "rich>=13.0"]
# ///
import redis
from rich import print

r = redis.Redis(host="localhost", decode_responses=True)
for key in r.scan_iter("session:*"):
    ttl = r.ttl(key)
    print(f"[cyan]{key}[/cyan] ttl={ttl}s")

uv run session_report.py   # 自动隔离环境运行，零残留

独特视角：PEP 723 + uv，实质上把"脚本即服务"的微思想落到了单文件级别。配合 uv tool 持久安装，你甚至可以 uvx session_report.py 把它当全局命令。这是 2026 年 Python 自动化运维最被低估的组合拳。

4.4 Workspace 单体仓库：uv 真正碾压 poetry 的地方

如果你在维护一个 monorepo（多个内部包互相引用），poetry 的 workspace 支持一直很弱，得靠 pip install -e . 或复杂路径 hack。uv 直接上了 Cargo 风格的 workspace。

根目录 pyproject.toml：

[tool.uv]
package = false   # 根不是可发布包

[tool.uv.workspace]
members = ["packages/*", "services/api"]

某个子包 packages/core/pyproject.toml：

[project]
name = "my-core"
version = "0.1.0"
requires-python = ">=3.11"

[tool.uv.sources]
# 引用 workspace 内其他包，无需发布到 PyPI
my-utils = { workspace = true }

services/api/pyproject.toml：

[project]
name = "my-api"
dependencies = ["my-core", "my-utils"]

[tool.uv.sources]
my-core = { workspace = true }
my-utils = { workspace = true }

然后一条命令同步整个单体仓库：

uv sync --all-packages --dev

uv 会把 my-core、my-utils 以**可编辑（editable）**方式链接进 my-api 的环境，改代码即时生效，无需 pip install -e 和路径黑魔法。这是 uv 相对 poetry 在"组织规模"上的代际优势：它把"多包协作"当一等公民设计，而不是事后补丁。

4.5 从 poetry 平滑迁移

老项目迁移不必推倒重来。实战路径：

# 1. 在已有项目根目录初始化 uv（非破坏性，会复用现有 pyproject）
uv init --bare        # 只写 uv 需要的最小配置，不覆盖你的代码
# 2. 把 poetry 的 dependencies 逐组迁进对应字段
#    [tool.poetry.dependencies]  -> [project].dependencies
#    [tool.poetry.group.dev]     -> [dependency-groups].dev
# 3. 生成锁文件
uv lock
# 4. 验证环境
uv sync --dev
# 5. 对比 poetry.lock 与 uv.lock 的解析结果，跑测试
pytest

迁移期最常踩的坑是 PEP 621 字段差异：poetry 用 [tool.poetry] 私有表，uv 遵循标准 [project] 表。把 name/version/dependencies 挪到 [project] 下即可，元数据更标准、对未来工具也更友好。

4.6 Docker 多阶段：把"可复现"焊进镜像

# ---- 构建期：只复制依赖声明，最大化缓存命中 ----
FROM python:3.12-slim AS builder
COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv

WORKDIR /app
ENV UV_COMPILE_BYTECODE=1 \      # 预编译 .pyc，省运行时编译
    UV_LINK_MODE=copy \           # 容器内用复制，避免 hardlink 跨层失效
    UV_PROJECT_ENVIRONMENT=/app/.venv

COPY pyproject.toml uv.lock ./
RUN --mount=type=cache,target=/root/.cache/uv \
    uv sync --frozen --no-dev     # --frozen：严格按 uv.lock，禁止改写

# ---- 运行期：极简 ----
FROM python:3.12-slim AS runtime
COPY --from=builder /app /app
WORKDIR /app
EXPOSE 8000
CMD ["/app/.venv/bin/uvicorn", "my_api.main:app", "--host", "0.0.0.0"]

两个细节决定成败：

--frozen：CI/构建里必须加。它禁止 uv 改写 uv.lock，保证"镜像里的依赖 = 仓库里锁定的依赖"，杜绝构建期静默升级。
RUN --mount=type=cache,target=/root/.cache/uv：把 uv 全局缓存挂成 BuildKit 缓存层，二次构建秒级。

4.7 GitHub Actions：缓存全局而非 .venv

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install uv
        uses: astral-sh/setup-uv@v3
        with:
          enable-cache: true          # 官方 action 自动缓存 UV_CACHE_DIR
      - run: uv sync --all-extras --dev
      - run: uv run pytest
      - run: uv run ruff check .

astral-sh/setup-uv 的 enable-cache 默认把 UV_CACHE_DIR 纳管进 GitHub Cache，比手写 actions/cache 缓存 .venv 稳得多——你拿到的是"从锁文件重建的可复现环境"，而非"一份可能过期的 venv 快照"。

五、性能优化：把 uv 榨到极致

速度默认就很快，但产线要的是"稳定地快"。几条经过验证的优化。

5.1 解析策略：默认 highest 不一定是你要的

uv 默认选最新兼容版本（highest），这利于拿到安全补丁。但有些团队要"最小变更"或"可复现到旧版本"：

uv sync --resolution lowest        # 全图选最低兼容版本（锁老环境用）
uv sync --resolution lowest-direct # 仅直接依赖取最低，间接依赖仍取最高
uv sync --prerelease allow         # 允许预发布版本（测新特性用）

环境变量等价写法：UV_RESOLUTION=lowest、UV_PRERELEASE=allow。CI 矩阵里用 lowest-direct 可以验证"你的代码在依赖最老版本下也能跑"，这是很多库的兼容测试标准姿势。

5.2 字节码预编译：省掉运行时编译

export UV_COMPILE_BYTECODE=1   # 安装时顺手编译 .pyc

冷启动场景（如 Lambda、短命容器）收益明显：省去首次 import 时的编译开销。CI 构建镜像时尤其值得开。

5.3 缓存目录与链接模式

场景	推荐配置
本地开发	`UV_LINK_MODE=hardlink`（默认，最省空间）
Docker 构建	`UV_LINK_MODE=copy` + BuildKit cache mount
NFS / 跨文件系统	`UV_LINK_MODE=copy` 或 `symlink`
CI 加速	缓存 `UV_CACHE_DIR`，开 `UV_COMPILE_BYTECODE`

5.4 给下游"不迁移 uv"的消费者导出锁

你团队用 uv，但部署平台只认 requirements.txt？uv export 反向兼容：

uv export --format requirements-txt --no-hashes --output-file requirements.txt
uv export --format requirements-txt --extra redis --hash > requirements.redis.txt

这样 uv 管开发，传统 pip 管部署，两边锁的是同一份真相。

5.5 基准：uv 到底快多少

Astral 官方 BENCHMARKS 显示，在"安装 Trio 依赖"这类场景，uv 比 pip 快 10~100 倍，创建虚拟环境约 10ms 级（pip+virtualenv 是秒级）。真实产线里，一个 300 包的服务：

pip install -r requirements.txt 冷缓存：~90s
uv pip install -r requirements.txt 冷缓存：~12s
uv sync --frozen（热缓存）：~1s

注意第三项——热缓存 + frozen 锁文件才是 uv 日常体感。它不是"偶尔快"，是"每次都快到感知不到"。

六、总结与展望：uv 改变了什么，以及它的边界

6.1 我的判断：uv 真正改变的，是"心智模型"

回到文章开头的论点。uv 最容易被记住的是速度，但速度只是表象。它真正做的，是把 Python 生态里互相不说话的 7 个工具，收敛成了一个有内聚设计、单一真相源（uv.lock）、且解释器与环境彻底解耦的系统。

这套设计带来三个过去做不到的事：

可复现性从"祈祷"变成"默认"：uv.lock + frozen + standalone Python，让"在我机器上能跑"第一次有了技术保证。
单体仓库从"黑客活"变成"一等公民"：Cargo 风格 workspace 让多包协作不再需要路径黑魔法。
工具链从"拼图"变成"单文件"：一个二进制覆盖安装、运行、版本管理、发包，新人第一天就能跑起来。

这恰好呼应了 2026 年整个开发者工具的大趋势——你回头看本站其他文章里提到的 TypeScript 编译器被 Go 重写、Bun 用 Rust 重写、Zed/Rust+eBPF 的崛起——"用系统级语言重写脚本级工具，并顺手统一碎片化的工具链"，是这两年最清晰的工程主线。uv 是这条主线在 Python 世界的代表。

6.2 uv 的边界：什么时候别用它

诚实地说，uv 不是银弹：

科学计算 / GPU 栈：如果你的依赖是 numpy/scipy/pytorch 且高度依赖 conda 的 MKL/ CUDA 构建，conda/micromamba 仍更稳。uv 能装 PyPI 上的 torch wheel，但conda 的渠道生态它不覆盖。
极致老旧环境：需要 Python 2.7 或古老 sdist 的项目，uv 不背这个锅。
强私有源 + 复杂认证：uv 支持 index 和 auth，但企业级多源镜像的坑仍需逐个踩（好在 UV_INDEX_URL、[[tool.uv.index]]、keyring 都给了出口）。

6.3 展望：uv 下一步去哪

2026 年 uv 已经在补齐最后两块拼图：

uv build / uv publish：构建 sdist+wheel 并直接发包到 PyPI（或私有源），把 twine 也收编。
自带 build backend：uv_build 作为 PEP 517 后端，让"构建"也成为 uv 内聚能力的一部分。

当这两块落地，uv 就真正成为 Python 世界的 Cargo / Go toolchain——从安装、开发、测试到发布，一个二进制闭环。对于 2026 年的 Python 工程师，我的建议很简单：新项目直接 uv 起手；老项目挑个依赖简单的先迁，尝到热缓存 + frozen 锁文件的甜头后，你会再也回不去那套七件套。

一句话收尾：uv 不是"更快的 pip"，它是 Python 依赖管理这场长达十五年的混乱，第一次有了"标准答案"的样子。

本文示例代码在 Python 3.11+/uv 0.5+ 验证可用，命令参数以你所用 uv 版本 uv --help 为准。生产配置请结合自身 CI 与私有源调整。

复制全文生成海报 uv Python 包管理 Rust 工程化 monorepo