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 评论区
81- notatallshaw
作为 pip 的维护者，我一直关注 uv 缓存的权衡取舍，这是 uv 相比 pip 在热安装（warm installs）速度上最大的优势所在。pip 缓存的是原始分发包，每次安装时都需要解压；而 uv 缓存的是已解压的分发包，并在可能时建立硬链接。
但它一直存在两个主要问题：
1. 无法为 "download" 命令精确复现分发包（uv 没有 "pip download" 的等价命令）
2. 对于拥有大量不同环境的用户，缓存增长远快于 pip
我很想看看（至少从经验上看），这次更新是否能显著改善第 2 点。如果是这样，我们或许就能采用双层缓存策略，而无需付出巨大的磁盘空间代价。
- mark_l_watson
不错的改进。对我来说，uv 就是 Python 界的 Quicklisp。uv 让我能像享受 Quicklisp 让 Common Lisp 变得更好用那样，享受使用 Python 的乐趣。
我一直都是 Lisp 的拥趸，但几年前开始使用 uv 后，我逐渐把 Python 视为一门真正能让我乐在其中的语言，因此我投入精力让我的 Python 开发环境几乎零摩擦。
- stephenlf
uv 是现代 Python 库的基石。我很期待看到这些改进。
- CivBase
用 4% 的性能下降换取 10% 的缓存空间缩减，在我看来似乎并不划算，尤其是当这还意味着复杂度的增加时。
- TacticalCoder
> 文件级去重：现在每个文件都存储在其 BLAKE3 哈希值下
Blake3 确实是一种极其快速的加密哈希算法。我在 LLM 出现之前就开发了自己的“去重/完整性校验/狂战士模式”工具，用的就是它。
如果我有一个名为：
DSC98731-b3-7b39197a22.JPG
的文件，那么：
- 如果该文件的校验和不匹配 7b39197a22，说明存在文件完整性问题（这太棒了，已经帮我排查过不少故障）
- 如果任何其它文件拥有相同的 Blake3 哈希值 7b39197a22，那它就是重复文件
- 如果该 7b39197a22 校验值存在于我的数据库中，那“事情就多了”。
例如，我的数据库可以规定：“任何 Blake3 哈希为 7b39197a22 的文件都可以直接删除”，或者“任何 Blake3 哈希为 887463c09e 且文件名是通用格式（如 'dscXXXXX'）的文件，都可以重命名为 '20260722jackJohnAtTheBeach-b3-778463c09e.jpg'（或者任何你喜欢的名字）”。
这真的非常棒（我知道这里有好几位独立开发过类似方案），而 Blake3 对于这类用途来说确实是一款惊人的哈希算法。