一个科研场景下的 Python 工作界面：编辑器中的代码调用 matplotlib 绘制物理模拟结果。此图不是 uv 的界面截图。图：MikeRun，来源 Wikimedia Commons，CC BY-SA 4.0。
uv 是 Astral 公司开发的开源 Python 包与项目管理工具，用 Rust 编写，可以统一管理 Python 版本、虚拟环境、依赖安装和锁文件。2026 年 10 月 19 日发布的 0.13.2 主要降低了复杂依赖解析的时间和内存开销，增强了环境信息导出，并修复了网址凭据可能泄露等问题。本文为资料核验，未安装实测。
项目源代码托管在 GitHub 的 astral-sh/uv 仓库（github.com/astral-sh/uv），官方文档位于 docs.astral.sh/uv。README 说明，uv 采用 Apache License 2.0 与 MIT 双许可证，使用者可任选其一。它的定位是用一个工具替代 pip、pip-tools、pipx、poetry、pyenv、twine、virtualenv 等多个工具，支持 macOS、Linux 和 Windows，可以用官方安装脚本安装，也可以 pip install uv。截至本文核验（2026 年 10 月 20 日），GitHub Releases 上的最新版是同日发布的 0.13.3，它只修复了一项性能问题：在含可选依赖（extras）的依赖图中，uv export 会严重变慢。近期功能层面的主要更新仍集中在 0.13.2。
对做计算研究的人来说，代码能不能跑通，常常取决于环境：同一份分析脚本，换一台电脑、换一个 Python 补丁版本或某个依赖的小版本，就可能报错或得到不同结果。uv 能把项目所需的 Python 版本和每个依赖的确切版本记录下来，让合作者和审稿人按同一份清单重建环境。下面依据官方文档和发布说明，介绍它在科研项目中的用法、近期版本变化和使用边界。
科研项目中的环境锁定
在项目模式下，pyproject.toml 声明项目需要哪些依赖及其版本范围，uv 解析后在同一目录生成 uv.lock。官方文档说明，uv.lock 是跨平台的通用锁文件，会按操作系统、处理器架构和 Python 版本等条件记录可能安装的每个包的确切版本，并建议把它提交到版本控制，让不同机器得到一致的安装结果。合作者克隆仓库后运行 uv sync 或 uv run，uv 会按锁文件创建或更新项目目录下的 .venv 虚拟环境。uv python pin 可以把 Python 版本写进 .python-version 文件，uv python install 可以下载指定版本的 Python；单文件分析脚本也可以在脚本内声明依赖，再用 uv run 在隔离环境中执行。
如果要复现一篇较早论文的环境，而原作者没有留下锁文件，可以用 --exclude-newer 只考虑某个时间点之前上传的包，例如设为论文投稿日期，这样后来发布的新版本不会进入解析结果。官方文档提醒，这里比较的是每个文件上传到包索引的时间，而不是版本号的发布日期；该选项只作用于从包索引获取的包，对 Git 依赖无效。uv.lock 是 uv 专用格式，需要交给其他工具时，可用 uv export -o pylock.toml 导出 PEP 751 标准化的 pylock.toml；习惯 pip 工作流的课题组，也可以用 uv pip compile、uv pip sync 等与 pip、pip-tools 用法相近的命令。
uv 项目环境复现流程示意：作者用 uv lock 生成 uv.lock，与 pyproject.toml、.python-version 一起提交到 Git 仓库，合作者克隆后运行 uv sync，按锁文件建立 .venv 虚拟环境；GPU 驱动、系统库、数据版本和随机种子不在锁文件范围内。流程依据 uv 官方文档 Structure and files 页整理。AI 生成示意图。
0.13.2 的改动与近期版本
0.13.2 于 2026 年 10 月 19 日发布（GitHub 记录的发布时间为 UTC 21:02）。性能方面，发布说明列出：简化、遍历和导出复杂依赖标记时避免指数级计算（依赖标记指“只在某个平台或某个 Python 版本下安装”这类条件）；减少解析和存储复杂标记所用的时间与内存；降低大型依赖图以及多环境分支、可选依赖、依赖组场景下解析器的内存占用；缓存成员名称，加快大型工作区的项目发现。对依赖众多、要同时兼容多个平台的科研代码仓库，这些改动主要影响 uv lock 和导出锁文件时的耗时与内存。发布说明没有给出具体提升幅度。
环境信息与安全方面，uv workspace metadata 现在会报告所有已安装的包，包括不在所选解析结果内的包；导出 pylock.toml 时会写入支持的环境限制，从 pylock.toml 安装或同步时也会遵守 PEP 751 规定的环境限制。获取包和索引数据时，中途断开的 GET、HEAD 请求会自动重试。修复项包括：防止网址中的凭据通过诊断信息或持久化元数据泄露；对只在敏感查询参数上不同的带签名 --find-links 网址分开缓存；缓存中已有更新的 wheel 时，仍然遵守 --exclude-newer 设定的时间上限。此外，按 PEP 825 获取和解析索引级“包变体”元数据（wheel-variants）目前仍是预览功能。
近两周的几个版本也与环境复现有关。0.12.24（10 月 8 日）修复了三个问题：为脚本环境指定精确的 Python 补丁版本时，不再跟随补丁升级而变化；即使用 --no-require-hashes 关闭了哈希强制要求，用户已经提供的哈希仍会被校验；约束或覆盖配置不再意外激活未选择的可选依赖。0.13.0（10 月 9 日）是包含破坏性变更的次版本更新：未指定或固定版本时默认下载的 Python 从 3.14 改为 3.15；从需求文件中用 -c 引入的约束文件里的 --require-hashes 开始生效；缓存格式也有调整，升级后可能需要重新下载或构建依赖。0.13.1（10 月 14 日）修复了并发读取时可能读到写了一半的锁文件或 Python 版本文件等问题。
局限与注意事项
uv 管理的是 Python 这一层的依赖。GPU 驱动和 CUDA、操作系统层面的系统库、数据版本、随机种子和硬件差异都不在锁文件的范围内，仍需借助容器、数据版本管理和实验记录等方式单独处理。锁定依赖是复现计算结果的必要条件之一，但不能单独保证结果可以复现。
版本策略上，官方文档说明 uv 用次版本号（如从 0.12 到 0.13）标记破坏性变更，补丁版本只包含修复、增强和其他非破坏性改动；uv.lock 的格式版本只会在次版本中变动。课题组共享项目时，建议在说明文档中写明所用的 uv 版本，跨次版本升级前先读发布说明。0.13.0 把默认下载的 Python 改为 3.15，没有固定 Python 版本的项目在新机器上可能装到与原作者不同的解释器，用 uv python pin 写明版本可以避免这种情况。预览功能可能随版本调整，不宜放进需要长期稳定的流程。