uv 缓存优化：文件级去重节省 10% 空间
uv: Deduplicate all files in the wheel cache
uv 项目迎来重大更新，charliermarsh 提交的新 PR 将 wheel 缓存的去重粒度从包级别细化到了文件级别。此前，uv 仅对重复的 wheel 包进行内容寻址缓存，而包内或跨包的重复文件仍会被重复存储。此次更新引入 BLAKE3 哈希机制，将所有文件统一存储在 files-v0 桶中，并通过硬链接映射到原位置。实测数据显示，这一优化在本地环境中节省了 545.2 MiB 的缓存空间，约占缓存总量的 10%。尽管冷启动安装速度有不到 4% 的轻微下降，但热安装性能未受影响，且显著减少了磁盘占用。这一改进在保持安装流程不变的前提下，极大提升了缓存效率。
我们在本地机器上节省了 545.2 MiB 的空间，约占缓存总量的 10%。
HN 评论区
121- notatallshaw
作为 pip 的维护者，我一直关注 uv 缓存的权衡取舍，这是 uv 相比 pip 在热安装速度上最大的优势所在。pip 缓存的是原始分发包，每次使用时都需要解压；而 uv 缓存的是已解压的分发包，并在可能时建立硬链接。
但它一直存在两个主要问题：
1. 无法为“下载”命令精确复现分发包（uv 没有对应 pip download 的命令）
2. 对于拥有大量不同环境的用户，缓存增长幅度远大于 pip
我很有兴趣看看（至少从经验上看），这是否能显著改善第 2 点，那样的话我们或许就能采用双层缓存策略，而无需承担巨大的磁盘空间成本。
- TacticalCoder
> 文件级去重：现在每个文件都按其 BLAKE3 哈希值存储
BLAKE3 确实是一种极快的加密哈希算法。我自己写过一个用于“去重/完整性校验/疯狂清理”的工具（那还是在 LLM 流行之前做的）。
如果我有一个名为：
DSC98731-b3-7b39197a22.JPG
的文件，那么：
- 如果该文件的校验和不匹配 7b39197a22，说明存在文件完整性问题（这太棒了，已经帮我排查过不少故障）
- 如果其他任何文件拥有相同的 BLAKE3 哈希值 7b39197a22，那就是重复文件
- 如果这个 7b39197a22 校验和在我的数据库里，那就可以“大干一场”了。
例如，我的数据库可以规定：“任何 BLAKE3 哈希为 7b39197a22 的文件都可以直接删除”，或者“任何 BLAKE3 哈希为 887463c09e 且文件名是通用格式（如 dscXXXXX）的文件，都可以重命名为 20260722jackJohnAtTheBeach-b3-778463c09e.jpg（或者你喜欢的任何名字）”。
这真的非常棒（我知道这里有好几位独立开发过类似方案），而 BLAKE3 对于这类用途来说确实是个绝佳的哈希算法。
- dboreham
人们说 uv 好是因为它快，但老实说我不在乎这个。我们改用 uv 来分发基于 Python 的工具，是因为它能非常方便地直接从 git 仓库安装，随后又能从同一仓库更新。完全不需要构建分发包。
- CivBase
为了换取 4% 的性能下降而减少 10% 的缓存大小，在我看来似乎并不划算，尤其是当这还增加了复杂度的时候。
- stephenlf
uv 是现代 Python 库的基石。我很期待看到这些改进。
- mark_l_watson
很棒的改进。对我来说，uv 就是 Python 界的 Quicklisp。uv 让我能像 Quicklisp 让 Common Lisp 变得更好用那样，尽情享受使用 Python 的乐趣。
我一直都是 Lisp 的忠实拥趸，但几年前当我开始使用 uv 后，Python 在我眼中变成了一种真正值得享受的语言，于是我开始努力让我的 Python 开发环境几乎零摩擦。