Go语言 - Tony Bai

本文永久链接 – https://tonybai.com/2026/02/05/brad-fitzpatrick-cachelink-reduce-go-test-wait-time

大家好，我是Tony Bai。

在维护大型 Go 单体仓库（Monorepo）时，你是否遇到过这样的场景：明明只是修改了测试的运行参数（比如 -run 的正则），或者在不同的 CI 节点上运行同一个包的测试，却发现 go test 依然在缓慢地执行“链接（Linking）”步骤？

对于代码量巨大的项目，链接过程往往是构建链条中最耗时的一环。为了解决这一痛点，Go 社区领袖、Tailscale 核心开发者 Brad Fitzpatrick 近日提交了 #77349 提案，建议引入 -cachelink 标志。这一看似微小的改动，有望在分布式测试和重复执行场景下，显著“挤出”原本被浪费的等待时间。

被忽视的瓶颈：重复链接的代价

Go 的构建缓存（GOCACHE）机制已经非常高效，它能很好地缓存编译阶段的中间产物（.a 文件）。但是，当你运行 go test 时，工具链的最后一步——将所有依赖链接成一个可执行的测试二进制文件——通常是“一次性”的。

这意味着，即使你的代码没有任何变动，只要测试指令稍有变化（例如多次运行 go test 但指定不同的测试用例），Go 工具链往往会重新触发链接器。

# 第一次运行：链接 + 执行
$ go test -run=^TestFoo$ ./pkg/

# 第二次运行（代码未变）：依然触发重新链接 + 执行
$ go test -run=^TestBar$ ./pkg/

对于依赖项数以千计的大型项目，链接过程可能长达数秒甚至更久。在本地频繁调试或 CI 流水线中，这些重复的秒数累积起来就是巨大的时间浪费。

Brad 的解法：-cachelink

Brad Fitzpatrick 的提案非常直接：允许将链接器输出的最终测试二进制文件，也写入 GOCACHE。

通过显式开启 -cachelink，go test 的行为将发生变化：

它会基于构建输入（代码、依赖、环境变量等）计算哈希。
如果发现 GOCACHE 中已经存在已链接好的测试二进制文件。
直接跳过链接步骤，复用该文件进行测试。

这样，上述例子中的第二次调用将瞬间启动，因为最耗时的构建步骤被完全省去了。

为什么不做成默认行为？

既然能提速，为什么不默认开启？Brad 在提案讨论中给出了专业的权衡分析：

空间 vs. 时间。

测试二进制文件通常包含完整的符号表和调试信息，体积比普通的中间对象文件大得多。如果默认缓存所有测试二进制文件，开发者的磁盘空间（GOCACHE）会迅速膨胀。因此，这是一个以空间换时间的策略，更适合由开发者根据项目规模手动开启，或者在 CI 环境中配置。

分布式 CI 的“加速器”

该提案真正的杀手级应用场景是分布式 CI 系统。

许多大厂使用 GOCACHEPROG 来在构建集群间共享缓存。在典型的 CI 流程中，测试任务往往会被分片（Sharding）到数十台机器上并发执行。

现状：每一台机器拉取源码后，都需要各自进行一次链接操作，浪费计算资源。
引入 -cachelink 后：第一台完成构建的机器会将二进制文件上传到共享缓存。后续几十台机器直接下载该文件并运行，全集群的链接成本降为“1”。

不仅是 go test -c

有经验的开发者可能会问：“我为什么不直接用 go test -c 手动编译成二进制文件，然后分发运行呢？”

Brad 指出，手动管理二进制文件会绕过 Go 原生的测试结果缓存。而 -cachelink 的精妙之处在于，它既复用了二进制文件，又保留了 go test 完整的缓存与输出管理体验。你不需要编写复杂的脚本来管理这些文件，一切依然由 go 命令自动处理。

小结

目前，该提案已进入活跃评审阶段，并有了初步的代码实现。对于深受“构建慢”和“测试慢”困扰的大型项目维护者来说，这无疑是一个值得期待的性能优化利器。我们有望在 Go 1.27 或后续版本中见证它的落地。

资料链接：https://github.com/golang/go/issues/77349

聊聊你的构建之苦

链接时间正在成为你的“带薪摸鱼”理由吗？在你的项目中，go test 运行一次通常需要多久？你为了缩短测试反馈周期，还尝试过哪些黑科技（比如 GOCACHEPROG）？

欢迎在评论区分享你的实战经验或吐槽！让我们一起期待 -cachelink 的落地。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

想写出更地道、更健壮的Go代码，却总在细节上踩坑？
渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/02/03/russ-cox-15-year-war-on-floating-point-conversion

大家好，我是Tony Bai。

“浮点数到十进制的转换一直被认为很难。但本质上，它们非常简单直接。” —— Russ Cox (2011)

“我错了。快速的转换器也可以很简单，这篇文章将展示如何做到。” —— Russ Cox (2026)

在计算机科学的深处，潜伏着一条名为“浮点数转换”的恶龙。将一个二进制浮点数（如 float64）转换为人类可读的十进制字符串（如 “0.1″），看似简单，实则是一个困扰了业界半个世纪的难题。

2011 年，Go 语言的核心人物 Russ Cox 写下了一篇博文，试图用一种简单的算法来“驯服”这条龙。然而，在随后的十几年里，学术界和工业界爆发了一场军备竞赛：Dragon4, Grisu3, Ryū, Schubfach, Dragonbox… 每一个新算法都试图在速度上压倒前一个，但也让代码变得越来越复杂，数学证明越来越晦涩。

2026 年初，Russ Cox 带着他的新系列文章强势回归。这一次，他不仅带来了一套比所有已知算法都更快的全新算法，而且证明了：极致的性能不需要极致的复杂性。

这套算法已被确定将在 Go 1.27 (2026年8月) 中发布。今天，我们就来深度解析这项可能改写浮点数处理历史的技术突破。

历史的迷宫与“不可能三角”

要理解 Russ Cox 的成就，我们首先要理解这个问题的难度。一个完美的浮点数打印算法，必须同时满足三个苛刻的条件（“不可能三角”）：

正确性 (Correctness)：转换必须是双射的。Parse(Print(f)) == f 必须恒成立。这意味着你不能随意丢弃精度。
最短性 (Shortest)：输出的字符串必须是所有能转回原值的字符串中最短的。例如，0.3 在二进制中无法精确表示，打印时应该是 “0.3″ 而不是 “0.2999999999999999889″。
速度 (Speed)：在大规模数据处理（如 JSON 序列化）中，转换速度直接决定了系统的吞吐量。

历史的演进：
* Dragon4 (1990)：实现了正确性和最短性，但依赖大整数（BigInt）运算，慢如蜗牛。
* Grisu3 (2010)：Google 的 V8 引擎引入。速度极快，但不保证最短性，约 0.5% 的情况会失败并回退到慢速算法。
* Ryū (2018) & Dragonbox (2020)：通过复杂的数学技巧（查表法），终于在不使用 BigInt 的情况下实现了正确且最短。这是性能的巅峰，但代码极其复杂，充满魔术数字。

Russ Cox 的目标，就是打破这个迷宫：能不能既像 Ryū 一样快且正确，又像 2011 年的那个算法一样简单？

核心技术——“未舍入缩放” (Unrounded Scaling)

Russ Cox 的新算法核心，源于一个极其精妙的数学原语：快速未舍入缩放 (Fast Unrounded Scaling)。

什么是“未舍入数”？

在传统算法中，我们总是纠结于“何时舍入”。Russ Cox 引入了 “未舍入数” (Unrounded Number) 的概念 ⟨x⟩。它由三部分组成：

整数部分: floor(x)
½ bit: 标记 x – floor(x) >= 0.5
sticky bit (粘滞位): 标记 x 是否有非零的小数残余。

这种表示法不仅保留了用于正确舍入（Round half to even）的所有必要信息，而且可以通过极其廉价的位运算（| 和 &）来维护。这就像是在计算过程中保留了一个“高精度的尾巴”，直到最后一步才决定如何截断。

缩放的魔法

浮点数打印本质上是计算 f = m * 2^e 对应的十进制 d * 10^p。核心步骤是将 m * 2^e 乘以 10^p。

Russ Cox 使用查表法（预计算 10^p 的 128 位近似值）来实现这一缩放。但他最惊人的发现是：在 64 位浮点数转换的场景下，我们甚至不需要完整的 128 位乘法！

他证明了：只需计算 64 位 x 64 位的高位结果，并利用低位的“粘滞位”来修正，就能得到完全正确的结果。这意味着，曾经需要几十次乘法或大整数运算的转换过程，现在被缩减为极少数几次 CPU 原生乘法。

这一发现被称为 “Omit Needless Multiplications”（省略不必要的乘法），它是新算法性能超越 Ryū 的关键。

从理论到 Go 1.27

基于这个核心原语，Russ Cox 构建了一整套算法家族：

FixedWidth: 定点打印（如 %.2f）。
Shortest: 最短表示打印（如 %g）。
Parse: 字符串转浮点数。

性能碾压

Russ Cox 在 Apple M4 和 AMD Ryzen 9 上进行了详尽的基准测试：

定点打印：新算法 (uscale) 显著快于 glibc 和 double-conversion，甚至快于 Ryū。
最短打印：在纯算法层面，新算法与业界最快的 Dragonbox 持平或更快，但代码逻辑要简单得多。
解析：同样基于该原理的解析算法，性能超越了目前业界标杆 fast_float (Eisel-Lemire 算法)。

更令人兴奋的是，Go 1.27 将直接集成这套算法或算法的一部分。对于 Gopher 来说，这意味着你的 fmt.Sprintf、json.Marshal 和 strconv.ParseFloat 将在下个版本中自动获得显著的性能提升，而无需修改一行代码。

证明的艺术

除了代码，Russ Cox 还做了一件很“极客”的事：他用 Ivy（一种 APL 风格的语言）编写了完整的数学证明。

他没有选择形式化验证工具（如 Coq），而是通过编写可执行的代码来验证算法在每一个可能的 float64 输入下都是正确的。这种“通过计算来证明” (Proof by Computation) 的方法，不仅验证了算法的正确性，也为后来者留下了一份可交互的、活生生的文档。

小结：简单是终极的复杂

从 2011 年的初次尝试，到 2026 年的最终突破，Russ Cox 用 15 年的时间完成了一个完美的闭环。

这一系列文章是一种工程哲学的胜利。它告诉我们：当我们面对复杂的遗留问题时，不要只是盲目地堆砌优化技巧。回到数学的源头，重新审视问题的本质，或许能找到那条既简单又快的“捷径”。

现在的 Go 标准库中，即将拥有一颗比以往任何时候都更强大、更轻盈的“心脏”。

资料链接：https://research.swtch.com/fp-all

你更看重哪一点？

在算法的世界里，正确性、最短表示、运行速度，这“不可能三角”总是让我们反复权衡。在你平时的开发中，有哪些场景曾让你被浮点
能或精度困扰？或者，你对 Russ Cox 这种“死磕 15 年”的工程精神有何感触？

欢迎在评论区分享你的看法！如果这篇文章让你对浮点数实现算法方面有了新的认识，别忘了点个【赞】和【在看】，并转发给你的Go开发朋友们！