垃圾回收 - Tony Bai

标签垃圾回收下的文章

别神话 Rust 重写了：搞定1%热路径，Go 性能照样起飞

五月 18, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/05/18/go-performance-optimization-over-rust-rewrites

大家好，我是Tony Bai。

近年来，如果你常年混迹于国内外各大技术社区，你一定会感受到一种近乎狂热的“政治正确”：带垃圾回收（GC）的语言都有原罪，万物皆可（且应该）用 Rust 重写。

从底层基础设施到上层业务逻辑，无数团队在遇到性能瓶颈时，脑海中蹦出的第一个念头就是：“Go/Java 搞不定了，由于 GC 停顿的存在，我们必须换 Rust 乃至 C++ 来重构核心模块。”

但这真的是解决性能问题的唯一出路吗？

最近，几位硅谷顶级的技术大佬——前 Tailscale CTO David Crawshaw、开源时序数据库 VictoriaMetrics CTO Aliaksandr Valialkin，以及资深底层代码大牛 Stewart Lynch，在 X（原推特）上掀起了一场关于“现代软件复杂性与性能优化”的讨论。

仔细研读他们的观点后，我得出了一个可能有些“反直觉”的结论：

对于绝大多数商业项目而言，盲目追求去 GC 化和无脑 Rust 重写，是一场灾难。真正顶级的性能优化，往往只需要对那 1% 的“热路径”动刀。

今天，我们就来揭秘这层信息差，看看顶级架构师是如何在不增加心智负担的前提下，把带 GC 的 Go 语言性能压榨到极致的。

现代软件最大的毒瘤：“不必要的复杂性”

为什么我们总是忍不住想要用极其复杂的语言或架构去重写现有的系统？

Stewart Lynch 在讨论中一针见血地指出了现代软件工程的通病：“Everything that’s wrong with modern software can be summed up in two words: Unnecessary Complexity”（现代软件所有的毛病，可以用两个词来概括：不必要的复杂性）。

这背后其实隐藏着一个程序员群体独有的心理学陷阱。

Lynch 解释道：“程序员这个群体有一个特殊的问题——我们往往是因为‘享受解决复杂问题’才选择这个职业的。我们热衷于理解极其复杂的东西并让它运转起来，我们是人类历史上最复杂结构的构建者。正因为如此，我们在任何地方都在寻找与复杂性搏斗的机会，即使在那些本该追求极简的地方。”

这就解释了为什么很多团队在面对一个简单的 CRUD 业务或者中等并发的微服务时，会毫不犹豫地引入极高门槛的语言（比如有着严苛借用检查器的 Rust）或是过度设计的服务网格。

因为“复杂，让人觉得高级”。

但结果是什么？

业务逻辑被切割得支离破碎，新员工入职需要花费两三个月才能看懂生命周期和指针所有权，团队的迭代速度断崖式下跌。你以为你在优化系统的性能，实际上，你在制造一场长期的维护灾难。在这个过程中，你消耗了大量的公司预算，仅仅是为了解决那些“想象中的未来问题”。

记住架构设计的第一法则：复杂性是优秀软件的死敌。

你的 99% 代码根本不需要瞎折腾

既然复杂性是死敌，那性能问题怎么办？难道我们就任由 GC 导致程序卡顿吗？

这时候，前 Tailscale CTO David Crawshaw 抛出了一个极具颠覆性的观点。他指出，整个行业现在正把海量的资源倾注到像 Rust 这样没有 GC 的程序中，但大家忽略了一个极其残酷的统计学事实：

“Almost all your code paths are cold and GC is net positive. 1% of your code is performance sensitive. Don’t create GC pressure there.” （你几乎所有的代码路径都是‘冷’的，在这些地方 GC 带来了纯粹的正向收益。只有 1% 的代码对性能真正敏感。你只需要不在那 1% 的地方制造 GC 压力就行了。）

什么是“冷代码”？

配置解析、路由分发、错误处理、数据库连接初始化、日志记录……在一个庞大的工程中，这部分代码占据了 99% 的体积。它们对微秒级的延迟根本不敏感。

对于这 99% 的代码，使用 Go、Java 甚至 OCaml 这样带有Full runtime GC的语言，是巨大的恩赐。GC 解放了程序员的大脑，让你不需要像写 C/C++ 或 Rust 那样，在写每一行代码时还要在脑海里进行“部分编译时规划（Partial compile-time planner）”。它让你可以把全部精力聚焦在“业务逻辑”本身。

人类解决复杂问题的能力，在不被内存分配分心时，才能发挥到极致。

为了那 1% 真正需要榨干 CPU 周期的核心逻辑，去强迫整个团队在剩下 99% 的冷代码中也要与内存所有权作斗争，这在商业 ROI（投资回报率）上是极其荒谬的。

这就是所谓“不要为了 1% 的醋，去包 99% 的饺子”。

VictoriaMetrics CTO 的 1% 极简榨干指南

好，逻辑理顺了：我们决定坚持使用 Go 语言，享受它极高的开发效率和并发优势。但我们确实遇到了那 1% 的核心瓶颈——比如高频交易的核心撮合引擎、时序数据库的底层写入循环。这部分代码极其吃 CPU，且 GC 带来的 STW（Stop The World）让人无法忍受。

不换语言，怎么破局？

别急，让我们来看看目前世界上性能最强悍的开源时序数据库之一：VictoriaMetrics 的做法。这个数据库完全是由 Go 语言编写的，但在各项 Benchmark 性能测试中，它经常把一众 C++ 和 Rust 写的时序数据库按在地上摩擦。

它的 CTO，Aliaksandr Valialkin 在这次讨论中，大方地分享了他“降维打击”般的优化路径。我将他的经验，结合各位大牛的讨论，为你整理成了以下三步走的“实操密码”：

放弃盲猜，用 Profiler 精准定位热路径（Hot Paths）

你永远不可能靠“直觉”找到性能瓶颈。Aliaksandr 强调，Go 语言拥有极度强大的内置 Profiler（pprof）。不要一上来就重构，先让程序跑起来，打入真实流量，然后用 pprof 精准定位出那消耗了 80% CPU 和大量内存分配的 1% “热路径”究竟在哪几个函数里。

这 1% 的代码，代码量往往极小，寻找它们并不困难。

在热路径中“完全移除”内存分配（Zero Allocation）

这是 Go 性能优化的核心灵魂。Aliaksandr 的原话是：“This is how I optimize programs written in Go – by removing memory allocations from hot paths…”。

只要你在热路径中不产生新的对象（不触发 malloc 和堆分配），垃圾回收器（GC）就根本不会被唤醒。没有分配，就没有垃圾；没有垃圾，就没有 GC 压力和停顿。

开启“逃生舱”：使用预分配与 Arena 机制

既然热路径不能分配新内存，那需要处理海量数据怎么办？大佬们给出了三种在 Go 中模拟底层语言内存管理的“逃生手段”：

预分配大块内存（Pre-allocations）：
正如 David Crawshaw 所举的例子，你可以在 Go 中一次性分配一个巨大的数组，比如：var x = make([]struct{…}, 1e6)。
这只产生一次大分配，然后你完全可以利用自己的算法，在这个预先分配好的内存块中进行指针的滑动和复用。对于 GC 来说，这只是一个单一的连续指针，GC 扫描它的成本极低，既能实现高并发，又极大地降低了 CPU 消耗。
对象池机制（sync.Pool）：
对于频繁创建和销毁的小对象，不要让它们落入 GC 的魔爪。利用 sync.Pool 将它们缓存起来，反复复用。
请求作用域内存竞技场（Arenas）：
Aliaksandr 提到了在处理网络请求时极其高效的 Arena 概念。在这个模式下，与单次 Request 相关的所有小对象分配，都在一个预先分配好的大块 Arena 中进行。当请求结束时，不需要逐个去释放对象，而是直接清空（free）整个 Arena。这几乎达到了和 Rust 一样零开销的内存清理效果，但代码写起来依然是熟悉的 Go 语法。

对 99% 的代码保持克制

当你在那 1% 的热路径里用尽了上述像 C 语言一样的“脏活累活”后，请立刻停手。

让程序剩下的 99% 保持最地道（Idiomatic）、最简单、最具可读性的 Go 代码。让 GC 去接管它们。

你会神奇地发现：你的程序不仅拥有了媲美 C++/Rust 的极致性能，同时你的团队依然保持着原本极高的业务迭代速度。

小结——顶级工程师与普通码农的终极分水岭

回顾这几位大佬的讨论，其实核心只指向了一个词：克制（Restraint）。

普通工程师总是试图寻找一种“银弹”——希望换一种时髦的语言，就能一劳永逸地解决架构、性能和内存安全的所有问题。他们沉迷于构建极其复杂的抽象体系，试图用技术上的炫技来掩盖业务上的平庸。

而真正顶级的架构师，深知商业的本质和团队运作的规律。他们懂得：

好的设计，就是当你不能再拿走任何东西的时候。 （正如评论区一位开发者所说：Good design is when you keep taking away things until you cannot take away any more.）
永远不要在全局引入复杂性。 遇到性能问题，先用监控定位，然后把性能敏感的那 1% 的代码隔离出来，在这个小黑盒子里用最极客的方式优化，最后把它严丝合缝地封装好。
拥抱不完美但高效的工具。 不要嫌弃 GC，懂得如何与 GC 和谐共处，才是真正的大师。

如果下次你的团队里，再有人因为某个接口慢了 10 毫秒，就嚷嚷着要用 Rust 把整个几十万行的后端服务重写时，请把这篇文章甩到他的脸上。

告诉他：“去把 pprof 打开，把那 1% 循环里的临时变量给我复用了，然后早点下班回家。”

资料链接：

https://x.com/valyala/status/2055725885035045234
https://x.com/stewartlynch8/status/2055322205563617516
https://x.com/davidcrawshaw/status/2055288855792955511

今日互动探讨：

在你的职业生涯中，是否经历过为了追求所谓的“极致性能”或“极客审美”，而导致整个项目陷入“过度复杂化（Over-engineering）”灾难的时刻？或者，你在使用 Go 语言时，有什么私藏的“热路径”压榨技巧？

欢迎在评论区留言和我探讨，我们一起对抗现代软件的“过度复杂病”。 （如果你觉得这篇文章打破了你的认知，别忘了点赞转发，让更多挣扎在重构边缘的兄弟们看到！）

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
构建坚不可摧的 Safety Middleware 与飞书人工审批防线
在底层实现 Token 成本审计、链路追踪与自动化跑分评估
从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

原「Gopher部落」已重装升级为「Go & AI 精进营」知识星球，快来加入星球，开启你的技术跃迁之旅吧！

我们致力于打造一个高品质的 Go 语言深度学习 与 AI 应用探索 平台。在这里，你将获得：

体系化 Go 核心进阶内容: 深入「Go原理课」、「Go进阶课」、「Go避坑课」等独家深度专栏，夯实你的 Go 内功。
前沿 Go+AI 实战赋能: 紧跟时代步伐，学习「Go+AI应用实战」、「Agent开发实战课」、「Agentic软件工程课」、「Claude Code开发工作流实战课」、「OpenClaw实战分享」等，掌握 AI 时代新技能。
星主 Tony Bai 亲自答疑: 遇到难题？星主第一时间为你深度解析，扫清学习障碍。
高活跃 Gopher 交流圈: 与众多优秀 Gopher 分享心得、讨论技术，碰撞思想火花。
独家资源与内容首发: 技术文章、课程更新、精选资源，第一时间触达。

衷心希望「Go & AI 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

img{512x368}

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

“用 Go 打天下，用 Rust 救火”：这才是 2026 年后端架构的唯一正解

五月 11, 2026
0 条评论

本文永久链接 – https://tonybai.com/2026/05/11/go-vs-rust-backend-architecture-the-2026-strategy

大家好，我是Tony Bai。

如果你经常逛各大技术社区，你一定会发现一个永远充满火药味的话题：Go 和 Rust，到底谁才是未来的后端霸主？

两派的支持者常常吵得不可开交。Go 开发者嘲笑 Rust 编译器像个严厉的教导主任，写个代码能让人掉光头发；Rust 开发者则鄙视 Go 的 GC（垃圾回收）带来的延迟毛刺，觉得它就是个“性能玩具”。

但在真实的商业战场上，这种“非黑即白”的零和博弈毫无意义。

最近，海外技术团队 CodeStax.Ai 发表了一篇文章，题目非常霸气：《Rust vs Go：2026 年唯一有意义的后端语言对决》。

这篇文章没有去纠结语法的优劣，而是直接从企业成本、团队扩张、以及系统演进的宏观视角，给出了一个极具颠覆性，却又务实到令人拍案叫绝的架构结论：

“用 Go 来构建（Build）系统，用 Rust 来优化（Optimize）系统。”

今天，我们就来拆解这套现代后端的终极生存哲学，看看顶级的架构师们，是如何在这对“冰与火”的语言中找到完美平衡的。

无情的现实：每一个后端系统，最终都会撞上“那堵墙”

在讲语言之前，我们必须先认清系统演进的残酷规律。

当你刚刚启动一个新项目时，一切都很美好。

你用微服务框架快速拉起几个 API，部署到 AWS 的容器服务（ECS）里，挂上消息队列（SQS）。一切都运转良好：接口响应很快，团队每个星期都能迭代新功能，老板很开心，每月的云服务器账单也完全在可控范围内。

直到有一天，增长（Growth）发生了。

流量呈指数级上升。突然之间，原本平稳的系统开始出现各种诡异的症状：

系统的内存占用越来越大，云账单的增长速度开始远远超过业务的增长速度。
在毫无征兆的流量高峰期，API 出现了莫名其妙的延迟毛刺（Latency Spikes）。
微小的性能低下，在每天几亿次的调用中，被复利放大成了拖垮整个集群的致命瓶颈。

这就是所有后端系统迟早都会撞上的“那堵墙（The Wall）”。

当撞墙的那一刻，老板问你的问题，将不再是：“我们最快多久能把这个功能做出来？”

而是变成了极其致命的灵魂拷问：

“我们如何在不拖慢业务团队开发速度的前提下，让这个庞大的系统保持稳定、高效，并且把那该死的云账单降下来？”

正是在这堵墙面前，Go 和 Rust 的选择，才真正具有了生死攸关的意义。

Go 的主场：敏捷与编排的绝对王者

在跨越“那堵墙”之前的大部分时间里，以及在墙外 80% 的业务场景中，Go 语言是毫无争议的默认王者。

为什么？因为现代的后端架构，本质上不再是写一个庞大的单体应用，而是在做“服务编排（Orchestration）”。

你需要一个 API 网关来接收请求，需要一个个微服务去读写数据库（RDS），需要 Worker 去消费消息队列（Kafka），还需要后台的定时任务去跑批处理。

这些错综复杂的分布式场景，对语言的要求出奇的一致：

启动要极快：为了适应容器和 Serverless（Lambda）的弹性伸缩。
并发要极简：遇到高并发？随手 go func() 就能轻松应对 SQS 消费和扇出（Fan-out）模型。
心智负担要极低：代码必须像白开水一样直白。今天刚入职的应届生，明天就能看懂并修改跑了三年的核心代码。

Go 语言完美地满足了这一切。它的设计哲学就是：“天下武功，唯快不破；保持简单，拒绝炫技。”

在 Go 的世界里，开发者的个人时间，永远比 CPU 的计算时间更昂贵。它用“相对够用”的性能，换取了团队极高的迭代速度和代码的一致性。

这就是为什么，Go 语言统治了业务服务的“编排层（Orchestration Layer）”。

Rust 的拔剑：在深水区里，手撕性能瓶颈

然而，当你的系统撞上“那堵墙”，当系统中某些特定的组件，变成了吞噬资源的黑洞时，Go 语言的 GC（垃圾回收）和相对粗放的内存管理，就会显得力不从心。

这个时候，就是 Rust 拔剑出鞘的时刻。

Rust 不适合用来写那些三天两头变需求的业务 CRUD 接口，它真正的主战场，是系统里那些承担“重体力劳动（Heavy-lifting components）”的深水区：

高吞吐量的消息处理器：比如每天要吞吐数百亿条记录的 Kafka 消费者集群。
实时流处理和欺诈检测引擎：在这些场景下，哪怕是几十毫秒的 GC 停顿，都会导致不可估量的经济损失。
成本敏感的边缘计算（Edge Compute）：在资源极其受限的环境中榨干最后一滴 CPU 性能。

在这些领域，Rust 的设计哲学展现出了降维打击般的威力：“控制所有重要的事情。”

Rust 假设：线上的 Bug 是极其昂贵的；规模化后的性能低下是致命的。因此，它用极其严苛的编译器，强迫你在写代码的阶段就解决掉所有可能的内存泄漏和并发竞争。

它没有 GC，内存效率极高。在 CPU 密集型的任务中，它通常比 Go 快 2 到 5 倍。

终极兵法：双剑合璧的实战演练

聪明的架构师早就看透了：我们不需要在 Go 和 Rust 之间二选一，我们需要的是将它们各自部署在正确的战线上。

在真实的硅谷大厂和独角兽公司中，最经典的架构模式已经浮出水面：

Pattern 1：用 Go 写服务层，用 Rust 写热点路径（Hot Path）

让 Go 去处理绝大多数的 API 路由、微服务间通信和业务编排。这保证了团队的开发速度。
一旦监控发现某个模块成了 CPU 或内存的瓶颈（比如音视频转码、核心推荐算法），立刻将其剥离，用 Rust 重写，作为一个独立的高性能微服务被 Go 调用。这种“好钢用在刀刃上”的策略，避免了过度工程化。

Pattern 2：为成本和延迟而战

当你的 AWS ECS 集群因为某个 Go 写的聚合管道而不断扩容，云账单即将失控时；或者当你的金融系统要求绝对可预测的执行时间，不能容忍任何 GC 暂停时。
毫无犹豫地让 Rust 进场接管。它省下的机器成本，足以支付重写代码的代价。

小结：别为了追求“最好”，而忘记了“为什么出发”

最后，我想分享一下我最喜欢的一段话：

“在这个世界上，你永远无法通过选择一门‘最好的语言’来赢得战争。”

“你赢得战争的方式是：深刻理解你的系统会在哪里崩溃；知道哪种工具能精准地解决那个特定的问题；并且，只有在确实能带来巨大回报的地方，才引入复杂性。”

如果你的系统还在为了活下去而疯狂堆功能，请闭上眼睛，用 Go 语言全力冲刺。

如果你的系统已经庞大到每次发版都在流血，每多消耗 1MB 内存都在烧钱，那么，请翻开 Rust 的手册。

用 Go 来构建你的商业帝国，用 Rust 来捍卫它的边界。

这，才是 2026 年，一个成熟架构师应有的顶级大局观。

资料链接：https://codestax.medium.com/rust-vs-go-the-only-backend-language-comparison-that-actually-matters-in-2026-6b8303dbb7c2