GC - Tony Bai

本文永久链接 – https://tonybai.com/2025/12/30/high-concurrency-backend-go-vs-rust

大家好，我是Tony Bai。

在高并发后端开发领域，Go 语言曾是当之无愧的“默认选项”。然而，随着 Rust 生态的成熟和性能神话的普及，越来越多的架构师开始动摇：是继续坚守 Go 的高效与简洁，还是拥抱 Rust 的极致性能与零成本抽象？

近日，r/golang 社区的一场热议将这一抉择摆上了台面。这不仅是语言之争，更是关于工程效率、系统复杂度与团队协作的深度博弈。本文将基于这场高质量的社区讨论，为你梳理出理性决策的核心逻辑。

img{512x368}

坚守 Go 的理由——“早点下班”的生产力

在讨论中，尽管 Rust 呼声很高，但支持坚守 Go 的声音依然占据了工程实践的主流。理由惊人地一致：生产力 (Productivity)。

“可用的软件 > 早期的优化”

一位Reddit 用户的高赞回答道出了软件工程的真谛：“使用让你高效的工具。可用的软件 > 早期的优化。”

对于绝大多数后端业务来说，瓶颈往往在于数据库、网络 I/O 或者架构设计，而不是语言本身的 CPU 执行效率。Go 语言的设计初衷就是为了解决谷歌规模的软件工程问题——快速编译、快速部署、易于阅读、易于维护。选择 Go，意味着选择了更快的交付速度。

“足够好”的并发性能

Go 的 goroutine 和 channel 使得并发编程变得前所未有的简单。正如一位用户所言：“Go 依然是处理高并发请求的王者，因为它简单、易于测试、易于优化。”

在 99% 的场景下（例如 QPS < 100k），Go 的性能已经绰绰有余。为了追求 Rust 那最后 5% 的性能提升，而牺牲 50% 的开发效率，对于大多数追求商业闭环的项目来说，是一笔亏本买卖。

人才与生态的护城河

“如果你不是在造火箭，Go 是大多数公司的最佳选择。” Go 拥有庞大且成熟的云原生生态系统（Docker, K8s, Etcd…），以及大量(相对于Rust)容易招聘的工程师。相比之下，Rust 的学习曲线陡峭，人才库相对较小，且招聘与薪资成本更高。

拥抱 Rust 的动力——当“每一字节”都至关重要

当然，Rust 的崛起并非空穴来风。社区也客观地分析了拥抱 Rust 的必要场景——那些 Go 力不从心 的极端领域。

极致的资源控制

当你的应用对延迟极其敏感（P99 要求极高），或者需要处理海量数据且对内存占用有严格要求时（例如高频交易、嵌入式系统、数据库内核），Go 的 GC (Garbage Collection) 带来的停顿就成了无法忽视的痛点。此时，Rust 的无 GC 特性就成为了杀手锏。

一位用户指出：“当 QPS 超过 100k，或者你需要榨干硬件的每一个周期时，Go 的 GC 可能会成为瓶颈，这时 Rust（或 C++）才是更好的选择。”

“编译期正确”的安全性

Rust 的借用检查器虽然让初学者头疼，但它在编译期就消灭了数据竞争和内存安全问题。对于那些绝对不能崩溃的关键基础设施（如数据平面代理），Rust 提供了比 Go 更强的安全保证。拥抱 Rust，意味着用编译时的痛苦换取运行时的安心。

工程视角的理性决策

这场讨论最终回归到了工程权衡 (Trade-offs) 上。我们不应在真空中做选择，而应根据业务场景裁决：

业务开发：坚守 Go。CRUD、微服务、Web API……Go 写起来快，改起来也快，心智负担低，是构建业务逻辑的首选。
基础设施：分层选择。Go 依然是控制面（Control Plane）的主流（看看 K8s），但在更底层的数据平面（Data Plane，如 Envoy, Linkerd 的代理部分），拥抱 Rust 正在成为趋势。
混合架构：一种越来越流行的模式是——用 Go 写控制面和业务逻辑，用 Rust 写核心的高性能组件。正如一位用户所分享：“我用 Rust 写内核模块和 IO 密集型组件，用 Go 写扩展性后端和 OLAP 管道。”

小结：服务于目标的决策

高并发后端的选择，本质上不是非黑即白的站队，而是对项目目标的精准匹配。

如果你追求快速交付、易于维护、团队协作顺畅，Go 依然是后端开发的默认选项。
如果你遇到了极端的性能瓶颈，或者需要极致的内存安全，那么 Rust 是你强大的特种武器。

不要为了技术而技术。正如一位智者所言：“Done is better than perfect.” (完成比完美更重要)。在你的产品还没遇到 Go 的性能瓶颈之前，先用 Go 把它做出来吧！

资料链接：https://www.reddit.com/r/golang/comments/1pi3914/is_go_still_the_best_choice_for_highconcurrency

你的选择是？

在这场“生产力”与“极致性能”的博弈中，你的团队选择了哪条路？ 是坚守 Go 的高效交付，还是为了 5% 的性能提升而转向 Rust？又或者，你们已经开始了“混合架构”的尝试？

欢迎在评论区分享你的选型逻辑和实战经验！ 让我们一起看看大家都在怎么选。

如果这篇文章帮你在技术选型上理清了思路，别忘了点个【赞】和【在看】，并转发给还在纠结的架构师朋友！

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

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

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

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

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

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

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

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

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

本文永久链接 – https://tonybai.com/2025/12/05/proposal-runtime-secret

大家好，我是Tony Bai。

“如果你的服务器被攻破，攻击者能否拿到内存中残留的私钥，进而解密过去两年的所有通信记录？”

这是一个让所有安全工程师夜不能寐的问题。为了防止这种情况，现代加密协议（如 TLS 1.3, WireGuard）都强调前向保密 (Forward Secrecy)：使用临时的、一次性的密钥，并在使用后立即销毁。

然而，在 Go 语言中，“立即销毁”这个看似简单的动作，却是一个巨大的技术难题。由于垃圾回收 (GC)、堆栈复制、以及缺乏对内存的底层控制，Go 程序很难保证敏感数据被彻底擦除。

针对这一痛点，Go 社区大神 Jason A. Donenfeld(WireGuard作者，ID: zx2c4) 发起了一项长达数年的提案——引入 runtime/secret 包。近日，该提案已进入实现阶段，有望在Go 1.26版本中落地，并彻底改变 Go 处理敏感数据的方式。

img{512x368}

核心痛点：为什么 memset(0) 在 Go 中不够用？

在 C 语言中，我们可以调用 explicit_bzero 来擦除内存。但在 Go 中，情况要复杂得多：

隐式拷贝：Go 的切片操作、函数传参、甚至简单的赋值，都可能在堆或栈上留下数据的副本。你擦除了一份，却可能漏掉了其他三份。
GC 的不确定性：垃圾回收器何时运行？被回收的内存是否会被立即归零？这些都是未知的。
堆栈扩容：当 goroutine 栈空间不足时，Go 运行时会分配一个更大的新栈，并将旧栈的数据拷贝过去。旧栈中的敏感数据就此残留，且不再被追踪。
编译器优化：简单的“写入零值”操作可能会被编译器视为“死代码”而优化掉。

正如 WireGuard 的 Go 实现中遇到的尴尬局面：为了擦除一个 AEAD 对象中的密钥，开发者不得不使用反射 (Reflection) 这种“旁门左道”来重置其内部字段，既不优雅也不可靠。

提案及演进：从 SetZeroOnGC 到 secret.Do

这项提案的讨论过程，简直是一部 Go 运行时机制的“解剖学教程”。

早期尝试：SetZeroOnGC

最初的设想是让用户标记某个对象，告诉 GC 在回收它时必须将其内存归零。

但这无法解决栈上数据的残留问题，也无法处理那些在函数调用过程中产生的临时副本。

中期探索：自定义分配器与 SetFinalizer

有人提议使用 memguard 等库，通过 mmap 分配不受 GC 管理的内存。

但这需要重写所有加密库的 API，使其接受自定义分配器，工程量巨大且不兼容现有生态。

最终方案：runtime/secret 包

经过反复权衡，Go 团队和社区最终汇聚到了一个基于动态作用域的解决方案上。提案的核心 API 极其简洁：

package secret

// Do 执行函数 f。
// 当 secret.Do 返回时：
//   - 清除函数 f 执行期间创建的所有栈帧（stack frames）。
//   - 清除所有可能包含secret的寄存器。
//   - 在secret模式下栈增长时，清除旧的栈。
//   - secret模式下，在 f 执行期间分配的所有堆对象，会被标记为“敏感”，并在 GC 回收时被安全擦除。
//   - 如果函数出现panic，则将该panic提升为来自 secret.Do 的异常。这会从回溯中移除有关secret函数的任何信息。

func Do(f func())

这个设计不仅解决了堆内存的问题，更关键的是，它提供了一个“安全沙箱”。在这个沙箱内，你可以放心地进行加密计算，Go 运行时会负责清理你在栈上留下的所有痕迹。

使用场景：WireGuard 与 TLS

想象一下 WireGuard 的握手过程：

func handleHandshake() {
    secret.Do(func() {
        // 1. 生成临时私钥 (在栈上或堆上)
        ephemeralPrivateKey := generateKey()

        // 2. 计算共享密钥 (产生大量中间计算结果)
        sharedKey := computeSharedKey(ephemeralPrivateKey, peerPublicKey)

        // 3. 使用共享密钥进行加密操作
        // ...

        // 函数返回时：
        // - ephemeralPrivateKey 所在的栈帧被立即擦除
        // - sharedKey 等堆对象被标记，GC 回收时自动擦除
    })
}

开发者不需要手动追踪每一个变量，也不需要担心 copy 操作泄露数据。只要在 secret.Do 的闭包内，一切都是安全的。

深水区的挑战：信号、GC 与汇编

虽然 API 设计看似完美，但实现起来却是困难重重。今年的最新讨论揭示了几个令人头秃的底层挑战：

信号处理 (Signals)：如果程序在 secret.Do 执行期间收到系统信号，CPU 寄存器中的敏感数据会被操作系统保存到“信号栈”中。这相当于泄露了数据！
垃圾回收器 (GC)：GC 在扫描内存时，可能会将敏感指针加载到自己的寄存器或栈中。如何确保 GC 线程本身不泄露数据？这是一个极其棘手的工程问题。
汇编代码：Go 的加密库大量使用了汇编优化。如何确保这些汇编代码在使用完寄存器后正确地将其清零？

当然，目前该提案的开发者 Daniel Morsing 已经逐个克服了上述挑战，比如针对信号处理的问题，他提出了一种巧妙的“影子栈”方案，试图在信号处理返回前拦截并擦除这些数据。Daniel Morsing针对该提案的cl 704615 近期已经被merge，有望在Go 1.26落地。

不过目前，该secret包仅在linux for arm64 and amd64上有实现。

小结：安全是场持久战

runtime/secret 提案的推进，标志着 Go 语言在系统级安全领域迈出了重要一步。它不仅回应了高安全等级应用（如金融、国防）的需求，也体现了 Go 团队在面对复杂底层问题时的务实与坚持。

虽然已经被merge，但历史经验告诉我们，距离该功能成熟可能还有一段路要走，后续仍在会有一些问题和实现细节需要解决，但它所传达的信号是明确的：Go 正在成为编写安全基础设施的首选语言之一。

对于我们普通开发者而言，虽然我们未必会在业务代码中直接 import 这个包(runtime/secret)，但关注这个提案的进展，不仅能让我们见证 Go 语言如何填补安全拼图中至关重要的一角，更能让我们在“围观”其解决信号处理、GC 交互等硬核挑战的过程中，完成一次对 Go 运行时底层机制的深度认知升级。当这一基础设施最终就位时，我们将能以更强的信心，站在更坚固的安全基石之上构建应用。

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

聊聊你眼中的 Go 安全基石

runtime/secret 提案的推进，为 Go 在高安全等级场景的应用补上了一块关键的拼图。你在日常的 Go 开发中，是否也曾为如何安全地处理密钥、Token 等敏感数据而感到困扰？除了内存残留问题，你认为 Go 在安全方面还有哪些亟待完善的“深水区”？

或者，你对 secret.Do 这种通过“安全沙箱”来解决问题的方式有何看法？它是否是你心中理想的解决方案？

欢迎在评论区分享你的实战经验、安全痛点，或对 Go 语言安全生态的任何期待与建议！ 让我们一起探讨，共同构建一个更安全的 Go 世界。

如果这篇文章让你对 Go 的底层安全有了新的认识，别忘了点个【赞】和【在看】，并分享给更多关注 Go 安全的同伴！

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