本文永久链接 – https://tonybai.com/2026/04/30/ghostty-creator-leads-github-exodus-cto-apology-go-fix

大家好，我是Tony Bai。

在程序员的江湖里，GitHub 从来不仅仅是一个代码托管平台。它是开源精神的麦加，是数千万开发者的“赛博故乡”，是这个行业赖以运转的、最坚实的“基础设施”。

但就在近几个月，这座我们无比信赖的“圣城”，似乎正在走向“崩塌”。

4 月 28 日，Github 的第1299位用户，在自己的推特与博客上发表了一篇极其悲伤的“分手信”，标题是：《Ghostty Is Leaving GitHub》（Ghostty 正在离开 GitHub）。

这位用户，不是别人，正是 HashiCorp 的联合创始人、一手缔造了 Terraform、Vagrant、Vault、Consul 等一系列云原生和 Devops 神器的“教父级”人物——Mitchell Hashimoto。而 Ghostty，正是他当下倾注心血的、备受期待的新一代终端项目。

他在这封信中，用一种近乎“心碎”的口吻写道：

“写下这些让我感到莫名的悲伤。我从 2008 年 2 月开始使用 GitHub，至今已超过 18 年，横跨了我半个人生。……我曾深爱着 GitHub，胜过一个人应该去爱一个东西。但现在，我受够了。18 年了，我得走了。”

是什么，让这位曾经的“ GitHub骨灰粉”毅然决然地带着自己的“亲儿子”项目“出走”呢？

答案简单得令人窒息：GitHub 正在变得越来越不可用。

“在过去的一个月里，我用日记记录了每一次 GitHub 宕机对我工作的影响。几乎每一天，旁边都画着一个‘X’。就在我写下这些文字的时候，GitHub Actions 又挂了 2 个小时。……如果一个平台每天都要瘫痪几个小时，那它就不再是一个适合严肃工作的地方。”

Mitchell 的这封“分手信”，像一颗炸弹，瞬间引爆了整个技术圈。

就在文章发布的几个小时后，GitHub 的 CTO Vlad Fedorov 紧急发表了一篇官方博客，标题同样沉重：《An update on GitHub availability》（关于 GitHub 可用性的更新）。

在这篇近乎“道歉信”的回应中，GitHub 官方不仅承认了问题的严重性，更罕见地揭示了这场“可用性雪崩”背后的真正罪魁祸首，以及他们正在秘密进行的“技术自救”——其中，Go 语言扮演了至关重要的“救火队长”角色。

今天，就让我们来复盘一下这场由“分手信”引发的技术公案。

压垮骆驼的稻草：被 AI “撑爆”的古老架构

GitHub 到底怎么了？

在官方的回应中，CTO Vlad Fedorov 给我们展示了一张极其恐怖的增长曲线图：“Record Acceleration”（创纪录的加速）。

自 2025 年下半年以来，随着 AI Agent（智能体）编程工作流的急剧加速，GitHub 的各项核心指标都呈现出近乎垂直的指数级增长：

• 每月新增仓库数：2000 万
• 每月合并的 PR 数：9000 万
• 每月 Commits 数：14 亿

GitHub 官方坦言：

“这种指数级的增长，不是只对一个系统造成压力。一个 PR 会触及 Git 存储、合并检查、分支保护、GitHub Actions、搜索、通知、权限、API、后台任务、缓存和数据库。在巨大的规模下，微小的低效会被无限放大。”

队列加深、缓存击穿、索引落后……这些经典的分布式系统“并发症”，在 AI 制造的流量洪峰面前，被彻底引爆了。

Mitchell Hashimoto 的“出走”，只不过是压垮骆驼的最后一根稻草。

Go 语言的救赎：从 Ruby 单体地狱中“紧急救火”

面对这场史无前例的“流量洪水”，GitHub 的工程师们正在进行一场惊心动魄的“架构自救”。

在官方博客的What we’re doing一小节中，我们看到了一个熟悉的身影——Go 语言。

“我们加速了将性能或规模敏感的代码，从 Ruby 单体应用中迁移到 Go 语言的过程。”

这短短的一句话，信息量巨大。它揭示了 GitHub 这座“上古神殿”最核心的技术债之一：一些庞大、沉重、且难以扩展的 Ruby 单体应用。

在过去，当我们需要提升性能时，可能会选择更深入地优化 Ruby 代码，或者在前面加更多的缓存。

但在 AI 时代，这种“小修小补”可能已经毫无意义了。面对 10 倍甚至 30 倍的流量增长预期，唯一的出路，就是对系统进行“外科手术式”的重构。

为什么选择 Go 来“救火”？

因为 Go 语言几乎是为这种“救火”场景量身定制的：

1. 极致的性能与并发：Go 的性能远超 Ruby，其原生的 Goroutine 并发模型，能极其轻松地榨干现代多核服务器的性能，应对海量的网络请求。
2. 极低的资源占用：相比于 Ruby 或 Python 这种动态语言，Go 的内存占用更小、更可控，能极大地降低服务器成本。
3. 简单的部署：静态编译的单一二进制文件，使得将新的 Go 微服务部署到庞大的 Kubernetes 集群中，变得极其简单。

我们可以想象，在 GitHub 内部，正有无数个由 Go 语言编写的、小而美的微服务，像一支支训练有素的“消防队”，正在冲入火场，小心翼翼地从那个庞大的 Ruby 巨人身上，一块块地切下那些已经“燃烧”的性能瓶颈模块（如 Webhooks、认证授权、Git 操作等）。

Go 语言，正在成为 GitHub 这艘巨轮在 AI 洪流中，避免沉没的“压舱石”。

从“深情”到“决绝”：一个顶级开发者的 18 年之痒

Mitchell 的“分手信”，之所以能在社区引发如此巨大的共鸣，不仅仅是因为他的技术地位，更在于信中那份令人动容的“爱之深，责之切”。

他坦言，自己 20 岁时创建 Vagrant 这个成名作，很大程度上就是为了能获得一份在 GitHub 的工作。

“GitHub 是我的梦想。那里的工程师令人难以置信，产品令人难以置信。在过去的 18 年里，我每天都在呼吸着它的空气。”

“当我的感情经历挫折时，我把自己沉浸在 GitHub 的开源世界里；当我在大学里通宵时，我会在凌晨 4 点偷偷提交一个 commit；甚至在我的蜜月期间，我都会趁着妻子还在睡觉时，打开 GitHub。”

但正是这份深沉的爱，让 GitHub 的每一次宕机，都像一把刀子，刺在他的心上。

“这对我来说是私人的。我对 GitHub 的爱，超过了一个人应该对一个东西的爱。所以我对它感到愤怒。”

在文章的最后，他给所有“Git 是分布式的，你怕什么”的言论，给出了最沉重的回击：

“问题不在于 Git，而在于我们围绕它建立的、赖以为生的基础设施：Issues, PRs, Actions……如果它每天都要让你停工几个小时，那它就不再是一个适合严肃工作的地方。”

小结：当“基础设施”不再是理所当然

Mitchell Hashimoto 的“出走”，和 GitHub 官方的“道歉”，共同为我们揭示了 AI 时代一个极其深刻的现实：

当生产力工具的效率被提升 10 倍、100 倍时，它对底层基础设施稳定性的要求，也将被以同样指数级的规模放大。

我们曾经以为像水和电一样“理所当然”的 GitHub，正在成为整个行业发展的瓶颈。

这场危机，对 GitHub 来说是“生死存亡”的挑战，但对我们这些身处其中的技术人来说，又何尝不是一次“机遇”？

它告诉我们：

1. 基础软件领域，永远有仗可打。 当所有人都涌向应用层，去卷 AI Agent 的花活时，那些能用 Go 或 Rust，去重构和加固底层基础设施的硬核工程师，其价值将变得空前稀缺。
2. “稳定性”是最高的壁垒。 在一个功能可以被 AI 瞬间生成的时代，一个系统的长期价值，越来越多地体现在它的可用性、可靠性和可扩展性上。
3. 保持警惕，准备“B 计划”。 将所有的鸡蛋都放在 GitHub 这一个篮子里，可能不再是一个明智的选择。无论是自建 GitLab或Forgejo，还是探索其他新兴的代码协作平台，都值得我们重新审视。

旧神正在踉跄，新王尚未诞生。

在这场由 AI 引发的、史无前例的“基础设施大迁徙”中，你，准备好你的船票了吗？

资料链接：

• https://mitchellh.com/writing/ghostty-leaving-github
• https://github.blog/news-insights/company-news/an-update-on-github-availability/
• https://x.com/mitchellh/status/2049213597419774026

今日互动探讨：

在过去几个月里，你是否也曾被 GitHub 的频繁宕机所困扰？你认为 GitHub 这次“中年危机”的根源，真的是 AI 吗？还是其自身技术债的必然爆发？

欢迎在评论区分享你的看法！

还在为写 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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/04/29/go-1-27-default-simd-for-amd64-portable-simd-proposal

大家好，我是Tony Bai。

过去十年，Go 语言以其惊人的简洁和强大的并发能力，席卷了整个云原生领域。但在这片繁荣之下，一个尴尬的“阿喀琉斯之踵”，始终困扰着所有追求极致性能的 Gopher：

Go 语言，无法像 C++ 或 Rust 那样，原生且优雅地利用现代 CPU 的 SIMD（单指令多数据流）能力。

当你需要处理海量数据（如向量计算、图像处理、加解密）时，手写 Go 代码的性能，往往会被隔壁 C++/Rust 的 SIMD 优化版本，拉开数倍甚至数十倍的差距。为了榨干 CPU 的最后一滴性能，我们不得不去手写那些极其晦涩、难以维护、且无法被 GC 优雅调度的 Go 汇编。

但就在今年年初发布的Go 1.26版本中，这场长达十年的“性能怨念”，终于迎来了终结的曙光。Go 1.26以实验特性形式在AMD64架构上提供了SIMD的支持。

近期，Go 核心团队在官方 GitHub 仓库中，又密集地抛出了一系列重磅提案（#78902, #78979等）。这些提案不仅宣告了在 Go 1.26 中实验性加入的 SIMD 功能大获成功，更进一步宣布： 在即将到来的 Go 1.27 中，simd/archsimd 包将默认开启！同时，一个早已规划好的、架构无关的“可移植（Portable）”SIMD API 也已正式提案！

Go 团队试图用一种极其“Go-like”的优雅方式，为我们揭开 SIMD 这头性能怪兽的封印。

今天，就让我们来拆解这场 Go 语言的“性能下半场”革命，看看 Go 团队到底在下一盘怎样的大棋。

Go 的 SIMD 哲学：syscall vs os 的“两层模型”

要理解 Go 的 SIMD 设计，我们必须先看懂官方在 Issue #73787 中提出的核心哲学——“两层模型（Two-level approach）”。

Go 团队清醒地认识到，SIMD 的世界充满了矛盾：

• 底层：硬件指令集是非可移植的（Non-portable）。AMD64 上的 AVX512、ARM 上的 NEON/SVE、Wasm 里的 SIMD，它们的向量宽度、指令名称、甚至掩码（Mask）的表示方式都截然不同。
• 上层：Go 语言的核心魅力，恰恰是它的可移植性（Portability）。一份代码，处处运行。

如何调和这个矛盾？Go 团队从标准库中 syscall 和 os 包的关系里，找到了灵感。

第一层：simd/archsimd —— 你的“syscall”

这一层，是架构绑定的、低级别的。它将 CPU 的 SIMD 指令，近乎一对一地封装成 Go 的函数。比如 VPADDD 指令，就对应着 Uint32x4.Add()。

这一层追求的是极致的表达力和与硬件的零距离。它就是为那些需要手写汇编的“性能狂人”准备的。如果你想调用某个 AVX512 的独有指令，来这里就对了。

第二层：simd —— 你的“os”

这一层，将是架构无关的、高级别的。它会定义一套通用的、不依赖特定向量宽度的向量类型（如 simd.Float32s），以及一套通用的操作（如 Add, Mul）。

当你写下 a.Add(b) 时，编译器会根据你当前的编译目标（GOARCH），自动将其翻译成最高效的底层 archsimd 指令。

这一层追求的是极致的可移植性和易用性。对于 99% 的开发者来说，你只需要和这一层打交道。

硬核拆解：Go 1.27 即将转正的 simd/archsimd

在 Go 1.26 的 GOEXPERIMENT=simd 实验成功后，Go 团队在 Issue #78979 中正式提案，将 simd/archsimd for AMD64 在 Go 1.27 中默认开启！

让我们来一睹这把“屠龙刀”的真容：

1. 强类型的向量定义

告别 unsafe.Pointer 和丑陋的字节数组！archsimd 为不同位宽和数据类型，定义了极其清晰的结构体：

// 128位，4个 uint32
type Uint32x4 struct { a0, a1, a2, a3 uint32 }
// 256位，8个 float32
type Float32x8 struct { /* ... */ }

2. 易于理解的方法链

所有的 SIMD 操作，都被设计成了易于阅读和链式调用的方法。注释里甚至贴心地标出了对应的汇编指令。

// Add each element of two vectors.
//
// Equivalent to x86 instruction VPADDD.
func (Uint32x4) Add(Uint32x4) Uint32x4

3. 抽象的掩码（Mask）类型

如何处理不同架构下千奇百怪的掩码，是 SIMD API 设计中最头疼的问题。Go 团队选择了用一个不透明的 Mask 类型来屏蔽底层差异，让编译器自己去选择最高效的实现（K-register 还是 Vector-register）。

Go的野心：可移植的 simd 包提案出炉

如果说 archsimd 只是让 Go “追平”了 C++/Rust，那么 Issue #78902 中提出的高级 simd 包，则真正展现了 Go 语言的“野心”——在可移植性上，超越所有前辈。

在这个提案中，dr2chase 描绘了一个极其诱人的未来。你将可以这样写代码：

// 一个 inner product 示例
func ip(x, y []float32) float32 {
    var a simd.Float32s // 注意！这里没有指定位宽！
    var i int
    // a.Len() 会在运行时自动返回当前 CPU 支持的最佳向量宽度
    for i = 0; i < len(x)-a.Len()+1; i += a.Len() {
        u := simd.LoadFloat32Slice(x[i : i+a.Len()])
        v := simd.LoadFloat32Slice(y[i : i+a.Len()])
        a = a.Add(u.Mul(v))
    }
    // ... 处理剩余的尾部数据
    return sum(a) // 水平求和
}

sum函数在amd64平台的具体实现：

//go:build amd64
package main
import (
    "simd"
    "simd/archsimd"
)

func sum(x simd.Float32s) float32 {
    switch a := x.ToArch().(type) {
    case archsimd.Float32x8:
        a = a.AddPairsGrouped(a)
        a = a.AddPairsGrouped(a)
        return a.GetLo().GetElem(0) + a.GetHi().GetElem(0)
    case archsimd.Float32x16:
        s := make([]float32, a.Len())
        a.StoreSlice(s)
        var r float32
        for _, e := range s {
            r += e
        }
        return r
    case archsimd.Float32x4:
        s := make([]float32, a.Len())
        a.StoreSlice(s)
        var r float32
        for _, e := range s {
            r += e
        }
        return r
    }
    panic("not a known type")
}

看懂了吗？

你只需要写一份代码，把它扔到一台只支持 AVX2 的机器上，a.Len() 会返回 8；把它扔到一台支持 AVX512 的机器上，a.Len() 会自动变成 16！

编译器会自动为你生成多个版本的代码，并在运行时动态选择最优路径。这彻底将开发者从“为不同 CPU 手写不同优化版本”的地狱中解放了出来。

神仙打架：一场关于“命名哲学”的激烈辩论

在 Issue #73787 的评论区，一场关于 SIMD 函数命名哲学的“神仙打架”，精彩绝伦。

• 以 Ian Lance Taylor 为首的“专家派”认为：

  “应该直接使用 VPADDD 这样的汇编指令名。这对于专家来说更友好，他们不需要在脑子里多做一次‘Go 风格名称’到‘Intel 手册名称’的翻译。”

• 以 Cherry Mui 为首的“可读性派”则坚决反对：

  “代码的读者，远比代码的作者多。一个普通开发者能轻易猜出 Add 的意思，但绝对猜不出 VPADDD 是什么鬼。我们应该为读者优化，而不是为专家。”

最终，“可读性派”胜出。这也再次印证了 Go 语言一以贯之的设计哲学：明确性与可读性，永远高于一切。

小结：Go 语言的“性能下半场”

SIMD 的正式入场，标志着 Go 语言的演进，正在进入一个全新的阶段。

如果说过去十年，Go 靠着“并发”和“简洁”赢得了云原生的上半场；那么在未来十年，它将靠着这套兼具“优雅可移植”与“极致性能”的 SIMD 工具链，去硬刚 AI、数据科学、游戏引擎这些性能深水区（如果后续新版本的 AI 学会了如何使用这些新增SIMD特性）。

Go 团队没有选择像 C++ 那样直接暴露几百个晦涩的 Intrinsics，也没有像 Rust 那样在稳定性和表达力之间反复纠结。

它用一套极其深思熟虑的“两层模型”，试图在这场性能的终局之战中，走出一条属于自己的路。

Go 1.27，将是我们所有 Gopher 重新认识这门语言的开始。

那扇通往极致性能的大门，正在被缓缓推开。你，准备好了吗？

资料链接：

• https://github.com/golang/go/issues/73787
• https://github.com/golang/go/issues/78979
• https://github.com/golang/go/issues/78902

今日互动探讨：

在你的日常工作中，有哪些场景是目前 Go 语言性能的瓶颈，让你极其渴望 SIMD 的加持？对于 Go 团队设计的这套“两层 SIMD API”，你是更看好它的“可移植性”还是“性能潜力”？

欢迎在评论区分享你的看法！

还在为写 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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/04/28/go-conditional-expressions-propsal

大家好，我是Tony Bai。

在 Go 语言的江湖里，有一个话题，像幽灵一样，每隔几个月就会重燃战火。它引发的争论之激烈、持续时间之长，甚至超过了当初的“泛型”和“错误处理”。

它就是——三元条件运算符（Ternary Conditional Operator）。

condition ? then : else

这个在 C、Java、JavaScript 里被视为天经地义的语法糖，在 Go 的世界里，却成了一道不可逾越的“柏林墙”。

十几年间，无数开发者前赴后继地在官方 GitHub 仓库发起提案（从 Issue #23248 到 #33171 再到 #78865），用各种详实的数据和血泪案例，请求 Go 核心团队为这门以“简洁”著称的语言，补上这个“最该有”的特性。

但每一次，都遭到了 Go 团队近乎“铁板一块”的无情拒绝。官方 FAQ 里的那句“一门语言只需要一种条件控制流结构”，像一句神圣不可侵犯的教条，终结了所有讨论。

但就在前几天，这座最顽固的堡垒，似乎从内部出现了一丝松动。

Go 语言圣经《The Go Programming Language》的联合作者、Go 核心团队成员、Go 静态分析工具链的大神 Alan Donovan，亲自下场，发起了一个三元运算符的折中提案：Issue #78940。

他提出的新语法，试图在 Go 的“啰嗦哲学”与 C 的“简洁美学”之间，找到一条前人从未走过的“第三条路”。

今天，就让我们来深度复盘这场持续了 15 年的史诗级“内战”，看看 Go 团队为何对一个“小小的”三元运算符如此“深恶痛绝”，以及 Alan Donovan 的“折中提案”，能否为这场旷日持久的战争，画上句号。

为了一个简单的赋值，我被迫写了 5 行代码

让我们先回到一切争论的起点。

在曾经的提案 #78865 中，一位开发者贴出了一个让所有 Gopher 都感同身受的场景：

// 只是想根据一个 bool 值，给变量赋不同的字符串

var priority string
if t.Urgent {
    priority = "high"
} else {
    priority = "normal"
}

看懂了吗？一个在 C 语言里只需要一行 priority = t.Urgent ? “high” : “normal” 就能搞定的简单赋值，在 Go 里，我们被迫写了一个长达 5 行的、笨重的 if-else 流程控制块！

这位开发者甚至写了一个静态分析工具，扫描了包括 golang/go、kubernetes、terraform 在内的多个顶级开源项目。结果惊人：

平均每 6-7 个函数中，就有一个包含这种可以被三元表达式轻易优化的“啰嗦”模式。

这不仅仅是多敲几下键盘的问题。它背后隐藏着更深层次的哲学冲突：

• 三元运算符，是关于“值（Value）”的表达式。
• if-else，是关于“流程（Flow）”的语句。

用一个笨重的“流程控制语句”，去模拟一个轻巧的“值选择表达式”，在很多追求代码表达力的开发者看来，是一种彻头彻尾的“设计缺陷”。

核心团队的“铁壁”：我们到底在恐惧什么？

面对社区排山倒海的请愿，Go 核心团队（主要是 Ian Lance Taylor）为什么十几年如一日地坚决说“不”？

他们的核心论点，在 Issue #33171 的回复中，被总结得淋漓尽致：对“嵌套地狱（Nested Hell）”的恐惧。

在 C 语言中，一个新手程序员很容易写出下面这种连上帝都看不懂的“天书”：

result := a > b ? a > c ? "a" : c > b ? "c" : "b" : b > c ? "b" : "c"

这种缺乏明确括号和作用域的嵌套，极大地增加了代码的阅读和维护成本。

Go 语言从诞生之初，就对这种“隐晦”的复杂性深恶痛绝。它强制 if-else 必须带 {}，就是为了从语法层面杜绝当年 C 语言“悬挂 else”的经典歧义。

Go 团队的哲学是：宁愿让你多写几行“笨”代码，也绝不给你任何机会去写一行“聪明”的、但可能会让同事抓狂的“黑魔法”代码。

社区的声音：这是对开发者的“有罪推定”！

面对Go核心团队的“铁壁”，社区也给出了极其犀利的反驳声音。

一位开发者针对性地指出：

“导致代码不可读的风险，源于‘嵌套’，而不是三元运算符本身。Go 语言并没有限制你写出 15 层嵌套的 if-else。为什么你们相信开发者能管住自己的手不去滥用 if，却不相信他们也能管住手不去滥用 ?: 呢？”

这简直是灵魂拷问。

更重要的是，之前的提案者曾提出，可以通过 go vet 或 linter，在工具链层面直接禁止“嵌套三元表达式”的出现，只允许最简单的“扁平”形式。

Java、C++ 这些拥有三元运算符的工业级语言，早已形成了一套成熟的最佳实践。为什么 Go 社区就不能做到呢？

这种“一刀切”的拒绝，在很多开发者看来，是对整个开发者群体的一种不信任和“有罪推定”。

折中提案：Go 圣经作者的“第三条路”

就在双方僵持不下，ianlancetaylor 再次以“没有新信息”为由准备关闭提案#78865 时，Alan Donovan 出现了。

他没有直接支持经典的 ?: 语法，而是另辟蹊径，提出了一个折中的、极具“Go 语言特色”的语法提案：

(if cond then expr else expr)

这个提案的精妙之处，在于它完美地融合了双方的诉求：

1. 它是一个“表达式（Expression）”，而不是“语句（Statement）”

你可以直接用它来赋值：

role := (if isAdmin then "admin" else "user")

这彻底解决了用 if-else 语句进行赋值的“别扭感”。

2. 它强制使用括号 () 包裹

这是对 Go 语言“明确性”哲学的极致致敬。就像 if 强制使用 {} 一样，() 的强制使用，从语法层面彻底消灭了 C 语言 ?: 运算符在嵌套时产生的歧义和视觉混乱。

嵌套的写法会变得极其清晰（虽然也很丑，但这就是 Go 的目的——让你不想去嵌套它）：

(if (if cond1 then expr1 else expr2) then expr3 else expr4)

3. 它引入了一个新的关键字 then（或者用 ? 替代）

这使得语法在形式上，与传统的 if-else 语句产生了明确的区分，避免了解析器的歧义。

Alan Donovan 的这个提案，试图在“简洁表达力”和“语法无歧义”这两个看似不可调和的矛盾之间，找到一个平衡点。

它既满足了社区对“条件表达式”长达 15 年的渴望，又坚守了 Go 团队对“可读性”和“反魔法”的底线。

小结

Alan Donovan 的新提案（Issue #78940），目前已经被正式提交，并引发了新一轮的激烈讨论。

有人认为这是天才的设计，有人则觉得引入新关键字 then 的代价过高，不如直接用 ?。

这场争论的结果，我们还不得而知。

但它本身，就是 Go 语言魅力的一次完美展现。

它告诉我们：一门伟大的编程语言，其演进过程，从来不是核心团队的“一言堂”。而是在与社区的反复拉扯、辩论、甚至争吵中，不断地寻找那个“更不坏”的解。

Go 对“简单”的定义，也从来不是“代码行数最少”。

它追求的，是一种更高维度的简单——心智负担的最小化（Minimizing Cognitive Load）。

资料链接：

• https://github.com/golang/go/issues/33171
• https://github.com/golang/go/issues/78865
• https://github.com/golang/go/issues/78940

今日互动探讨：

你支持 Go 语言加入三元运算符（或条件表达式）吗？对于 Alan Donovan 提出的 (if cond then expr else expr) 这种新语法，你是拍手叫好，还是觉得多此一举？

欢迎在评论区分享你的看法！

还在为写 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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/04/27/render-why-we-wont-rewrite-in-rust-the-power-of-boring-go

大家好，我是Tony Bai。

在技术圈的鄙视链里，Go 和 Rust 这对“欢喜冤家”的战争，似乎从未停歇。

一方是追求极致简洁、被誉为“云原生时代的 C 语言”的 Go；另一方则是以内存安全、性能屠榜著称、被视为“C++ 终极替代者”的 Rust。

就在前些天，云平台 Render 的创始人兼 CEO Anurag Goel，在 X (Twitter) 上发布了一条看似平平无奇的“凡尔赛”推文，却意外地点燃了一场技术圈的论战。

他写道：

“我们在 Render 用 Go 语言（@golang）写的负载均衡器，每月处理超过 1500 亿次 HTTP 请求。”

“而我们想用 Rust 重写它的次数是：零。”

“Go 是基础设施领域最被低估的语言。‘无聊（Boring）’，才是它的终极特性。”

这篇充满“挑衅意味”的推文，像一块巨石砸入了平静的湖面，引得大量 Go 开发者欢呼雀跃，而 Rust 社区则瞬间被引爆。Cloudflare 的工程师更是直接下场，用自家 Rust 实现的、处理能力强 1000 倍的 Pingora 代理进行“数据反杀”。

今天，我们就来复盘这场“神仙打架”，看看在这场关于“无聊与极致”的哲学对撞背后，到底隐藏着怎样的工程思考。

隔空交火：Render 的 5.8 万 vs Cloudflare 的 5800 万

面对 Anurag Goel 的“凡尔赛”，评论区很快就出现了硬核的技术派。

一位的开发者迅速扒出了数据：

“Render 每月 1500 亿次请求，平均下来大约是 5.8 万 QPS。而 Cloudflare 当年之所以用 Rust 重写他们的代理（Pingora），是因为他们遇到了 5800 万 QPS 的瓶颈，大约是 Render 的 1000 倍。”

“所以，这根本就不是语言好坏的问题，而是在正确的场景，选择正确的工具。”

这段评论，精准地揭示了这场论战的第一个核心：场景与规模的错配。

在 5.8 万 QPS 这个量级，用 Go、用 Java、甚至用 Node.js，对于一个经验丰富的团队来说，都能轻松应对。Go 语言的简洁、极快的编译速度和成熟的并发模型，使其成为了 Render 在这个阶段的“最优解”。

正如另外一名开发者在评论中所言：

“如果一个系统已经在这个规模下稳定运行，那确实没有任何理由去切换技术栈。我能理解你的观点。但把 Rust 扯进来，只是为了强调 Go 的优点，感觉有点没必要。”

但这场论战，显然已经超出了纯粹的技术讨论范畴。

哲学对撞：Go 的“足够好” vs Rust 的“无限可能”

这场大讨论的真正引爆点，是另一位开发者抛出的一个经典“电车难题”：

“如果你的余生只能用一种语言写软件，你会选哪个？”
* Go
* Zig
* Rust

这个问题，瞬间将话题从“哪个工具更适合当前场景”，上升到了“哪种哲学代表未来”的形而上高度。

Go 的拥护者，信奉的是“80 分主义”和“极简主义”。

一位开发者 的评论极具代表性：

“我可能会选 Go。它是一种让你‘别挡路（get out of your way）’的语言。它的简单，让你能专注于你正在构建的东西本身，开发速度极快。”

对于 Go 的信徒来说，软件工程的本质，是在有限的时间和资源内，交付一个“足够好”的、能解决商业问题的系统。他们厌恶为了追求那最后 20% 的极致性能，而付出 80% 的额外复杂性代价。

而 Rust 的拥护者，追求的则是“确定性”和“无限的性能潜力”。

RisingWave（一个用 Rust 构建的流式数据库）的官方账号直接下场站台：

“我们选 Rust。Rust 已经不仅仅是一门系统编程语言，它正在成为现代数据基础设施的骨干。顶级的性能、内存安全……这才是基础设施应该有的样子。”

另一位开发者的评论则更加直接：

“Rust 确实比 Go 更好。但它还没好到值得让你把一个稳定的 Go 系统重写的地步。不过，如果你在乎快速的迭代周期，Rust 的编译时间可能会让你受伤。”

这完美地概括了两种哲学的核心冲突：

• Go：给你 80 分的性能和 95 分的开发效率。
• Rust：给你 100 分的性能和 100 分的运行时安全，但你可能要为此牺牲 50% 的开发效率和忍受漫长的编译等待。

AI 时代的变量：当“人类编写”不再是瓶颈

更有趣的是，这场发生于 2026 年的论战，不可避免地被卷入了 AI 编程的浪潮。

一位开发者提出了一个极具前瞻性的观点：

“（我选 Go），因为它现在是写 LLM 的最佳语言。”

这背后隐藏着一个正在成为行业共识的趋势：Go 语言的极简语法、强制的 gofmt 格式化、以及“一眼望到底”的直白控制流，使其成为了对大模型（LLMs）最友好的“编程母语”。当 AI Agent 生成一段 Go 代码时，人类审查的认知负荷是最低的。

而 RisingWave 则更认可正在成为现代数据基础设施的骨干的 Rust 在 AI 时代的潜力。随着 AI 应用对底层算子、向量数据库、推理引擎的性能要求越来越高，Rust 凭借其“零成本抽象”和对底层硬件的极致压榨能力，正在成为构建下一代 AI 基础设施的首选。

这形成了一个有趣的闭环：Go 负责让 AI 更方便地“写”应用层代码，而 Rust 负责构建让 AI 能够“跑”起来的底层高性能引擎。

架构师的终局：从“语言之争”到“问题之争”

在这场充斥着“拉踩”、“凡尔赛”和“信仰之争”的口水战中，我们依然能找到一条属于开发者架构师的、清晰的破局之路。

第一，警惕“语言的锤子”

当你手里只有一把锤子时，你看什么都像钉子。

正如一位开发者所言：“我的公司混合使用了 Go、Rust 和 Zig。最好的解决方案，永远是取决于具体问题的。”

一个优秀的架构师，脑海中不应该有“哪个语言最好”的执念，而应该有一个装着各种工具的“兵器库”，并清楚地知道每件兵器的适用边界和成本。

第二，承认“无聊”的价值

Render 创始人的那句“无聊是终极特性”，是对当下技术圈“追逐 Hype（炒作）”文化的一次降维打击。

一个能稳定运行、默默处理千亿流量的系统，其商业价值，远大于一个用了最新潮技术、却隔三差-五需要半夜起来救火的“实验品”。

对于绝大多数商业公司来说，技术的“可靠性”，永远高于技术的“先进性”。

第三，你的价值，不在于你用了什么语言

另外一位开发者的评论一语中的：

“大多数人会说 Rust。大多数团队依然会选 Go。而‘最好’的语言，是你能维护多年的那门语言。”

在快速变化的技术浪潮中，一个团队、一个公司的核心资产，从来不是某个用特定语言写就的代码库，而是对业务领域的深刻理解、对系统复杂度的掌控能力，以及在出现问题时能快速定位并解决的工程文化。

这些，都与具体的语言无关。

小结：你的选择是什么？

Render 创始人 Anurag Goel 的一条推文，无意间点燃了 Go 与 Rust 两个顶级社区的哲学大碰撞。

这场论战没有赢家，也不需要赢家。

它只是再次向我们证明了软件工程世界的多样性与复杂性。无论是 Go 的务实与简洁，还是 Rust 的严谨与极致，它们都是在用不同的路径，攀登着名为“构建可靠软件”的同一座高峰。

那么，回到最初的那个问题：

如果你的余生只能用一种语言，你会选择哪一个？

资料链接：https://x.com/i/trending/2044880265814978827

今日互动探讨：

如果让你来回答 Ben Dicken 的“电车难题”（Go, Zig, Rust 三选一），你的选择是什么？为什么？

欢迎在评论区分享你的站队和理由！

还在为写 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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/04/25/rust-popularity-vs-redmonk-ranking-reality-check

大家好，我是Tony Bai。

在过去几年的技术圈，Rust 是当之无愧的“流量之王”。

它连续多年在 Stack Overflow 开发者调研中蝉联“最受喜爱的语言”；它是 Linux 内核 30 年来引入的唯一非 C 语言；它是微软、亚马逊等大厂重塑底层安全架构的希望。

如果只看社交媒体和社区讨论，你会觉得 Rust 已经“统治了世界”。在一片赞歌中，大家默认 Rust 杀进主流榜单前十、取代传统语言只是时间问题。

但就在 2026 年 4 月，一份来自权威分析机构 RedMonk 的2026.1编程语言排行榜，却给所有“Rust 狂热者”泼了一盆透心凉的冷水。

数据呈现了一个极其残酷的反差：

在这份以“开发者真实选择”为核心指标的榜单上，Rust 的排名并没有像预期的那样一飞冲天，而是停滞在了第 20 位，甚至被曾被视为小众的 Dart 所超越。相比之下，那个常被调侃“无趣”的 Go 语言，依然稳稳地坐在第 12 位，并在云原生领域保持着统治地位。

为什么人人爱 Rust，但它在工业界的大规模普及却显得如此缓慢？为什么它“攻陷”了最硬核的 Linux 内核，却迟迟进不了普通开发者的日常？

今天，我想结合近期社区的深度讨论，扒开 Rust 这层华丽的外衣，带大家看看这门“天选之子”背后的生存现状与真实挑战。

口碑与数据的鸿沟：被锁死在“塔尖”的生产力

在开发者 Alejandra 最近整理的一份清单里，Rust 的“战绩”堪称辉煌：Windows 11 的核心组件、AWS 的 Firecracker 虚拟化、Cloudflare 的下一代代理服务器 Pingora……

但这恰恰揭示了 Rust 目前最大的尴尬：它是一个“属于 1% 的神兵利器”。

这些成功的 Rust 项目，无一例外都属于“系统级基础设施”领域。它们雇佣的是全球前 1% 的顶级程序员，拥有极其漫长的研发周期和近乎奢侈的调试成本。

正如 RedMonk 的分析师在报告中一针见血地指出：

“Rust 依然面临着非专家程序员难以逾越的学习门槛。专家们愿意投入时间，但更广泛的主流采用似乎面临着巨大的惯性。”

开发者 Alejandra 在其博文的自白中也坦言：

“无论我们如何自我安慰 Rust 已经进入主流，事实是：它离 C++ 甚至 Java 的普及程度，依然有着深不见底的鸿沟。大学教的第一门语言依然是 Java，飞机上依然在用 C++，网页里依然全是 Javascript。”

Rust 已经完成了从 0 到 1 的“极客突围”，却正在撞向从 1 到 N 的“工业化之墙”。

标准库的困局：当“技术洁癖”变成“协作负担”

除了学习曲线，Rust 进军主流的第二个障碍，也许就是它那小而美的标准库。

这篇名为《Unpopular opinion: Rust should have a larger standard library》（非主流观点：Rust 应该有一个更大的标准库）的帖子，戳中了无数一线开发者的泪点：

在我之前写过的一篇文章《别搞“小而美”了！Rust 开发者请愿：求求标准库学学 Go 吧》中也曾提过社区对 Rust 标准库的述求：

“我不想写个程序就要拉几百个三方库！生成一个随机数，std 里没有；想要个异步运行时，std 里也没有。我不得不把信任托付给几百个散落在 GitHub 各地、由个人维护的小型包（Crate）。”

这种对“核心精简”的极致追求，正在引发严重的“供应链安全焦虑”。

在 Go 的世界里，你可以用标准库完成 90% 的后端开发，这意味着你的核心链路是由 Google 顶尖团队直接背书的。但在 Rust 的世界里，开发者面临着“碎片化依赖”的内耗。

这种“标准库贫血”导致了一个反直觉的现象：Rust 是一门为了“安全”而生的语言，但它极度依赖社区包的机制，却在客观上增加了供应链被“投毒”的风险。

正如评论区所感慨的：“标准库是模块最终的坟场。”Rust 团队为了避免标准库变得臃肿，却无意中将“复杂性”和“审计成本”全部转嫁给了一线开发者。这种“技术洁癖”在处理顶级项目时是美德，但在处理追求效率的通用业务时，却成了巨大的阻碍。

Go vs Rust：工业生产力的两种极致审美

为什么 Go 能在 RedMonk 榜单上稳坐第 12，而 Rust 只能在第 20 徘徊？

这是两种完全不同的工程学审美，也决定了它们在大规模协作中的不同命运：

• Go 的审美是“工厂流水线”：它不鼓励个人英雄主义，它用 gofmt 强制所有人的代码长得一模一样。它追求的是“平均生产力的最大化”。即便是一个普通水准的程序员，在 Go 的框架下也很难写出摧毁系统的灾难性代码。这种“无聊”和“简单”，正是大厂进行大规模兵团作战时的首选。
• Rust 的审美是“顶级艺术工作室”：它追求极致的精准、极致的控制。每一个 borrow，每一个 lifetime 都是在进行微雕。它追求的是“个体生产力的上限”。

但在现代软件工业中，“下限的稳定性”往往比“上限的惊艳度”更具普适价值。 绝大多数公司需要的不是一个能手搓编译器的天才，而是一群能够按照既定流程、稳健产出、且易于维护代码的合格工程师。

AI 时代的变数：谁才是对机器最友好的母语？

RedMonk 的报告里还提出了一个极具前瞻性的观察：理论上，AI 编码辅助工具应该能抹平 Rust 的学习曲线，但现实并非如此。

为什么？

大模型（LLM）的本质是模式识别和概率预测。

对于语法单一、推崇“唯一路径”的 Go 语言来说，AI 生成的代码准确率极高，且人类审查的认知负荷极低。

而对于规则极其复杂、生命周期标记繁琐的 Rust 来说，AI 生成的代码极易出现“微妙的语法错误”或“不地道的生命周期设计”。人类开发者在审查 AI 生成的 Rust 代码时，往往比自己重写一遍还要痛苦。

在“机器写代码”即将接管开发流程的未来，简单、标准、甚至有些“死板”的语言，反而拥有更宽、更深的护城河。《HashiCorp 创始人亲口“认错”：AI 让我重新爱上了 Go (文末福利)》一文中Hashicorp创始人Mitchell Hashimoto 因 AI 重新爱上Go，以及Pandas 之父近期更喜欢让 AI 用Go写代码也印证了这一点。

小结：架构师的清醒与权衡

作为一个架构师，我们不必因为 Rust 在榜单上的“冷水”而否定它的伟大。

Rust 正在解决软件工程中最难的问题——在不牺牲性能的前提下，从根源上消灭内存漏洞。它的价值，已经在 Linux 内核和那些“不容有失”的领域得到了证明。

但我们也必须清醒地认识到：技术的流行度（Popularity）与技术的高级感（Elegance）并不总是正相关。

如果你在构建下一代安全操作系统、数据库内核或高性能边缘网关，Rust 是你不二的利剑。

但如果你在构建一个需要快速迭代、支撑公司核心营收、且由几十甚至上百人协作的后端业务系统，请务必保持客观：那个排名第 12、虽然有些“平庸”但永远能准时交付、且对 AI 极度友好的 Go，或许才是那个更优的工程方案。

再次祭出那句话：你的技术护城河，从来不是由你用什么语言决定的，而是由你解决问题的深度，以及你在各种极端权衡（Trade-offs）中做出的选择决定的。

资料链接：

• https://blog.goose.love/posts/what-actually-uses-rust/
• https://www.reddit.com/r/rust/comments/1sqyjxa/blog_ok_what_actually_uses_rust/
• https://redmonk.com/sogrady/2026/04/14/language-rankings-1-26/

今日互动探讨：

看完这份“人人爱 Rust，但榜单很冷酷”的现实反差，你觉得 Rust 挺进主流最大的障碍是什么？你认为“大标准库”是未来编程语言的必然趋势吗？

欢迎在评论区分享你的看法！

还在为写 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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/04/24/go-code-design-day-one-principle-practical-patterns-list

大家好，我是Tony Bai。

世界读书日送福利活动火热进行中，点击这里留言参与，赢取属于你的幸运！

每一个 Go 开发者，大概都经历过这样的心路历程：

项目启动初期，为了追求“快”，我们怎么方便怎么来。配置到处写，数据库连接随手建，错误日志直接 fmt.Println。我们安慰自己：“先跑起来，以后再重构。”

结果呢？

半年后，项目变成了一座摇摇欲坠的“屎山”。配置散落在几十个文件里，改一个端口号要动十个地方；数据库连接池因为没关，把连接数打满；线上出了 Bug，日志里只有一行孤零零的 record not found，查个问题比登天还难。

技术债，就像滚雪球，你越是假装看不见，它就滚得越大。

这时候，你的内心肯定在呐喊：有没有一些在Go项目刚创建时期就应该知道的Go代码模式，可以让我在项目的“第一天”，就建立起一套健壮、可维护、可观测的骨架呢！

有的！

我将这套方法论，称为 Go 语言架构的“第一天原则”。掌握它，足以让你在Go 代码设计的道路上，少走五年弯路。

这些原则，没有一条是关于炫技的复杂设计模式。

今天，我们就来逐条硬核拆解这些原则，并用可运行的 Go 代码，手把手教你如何将它们落地。

原则一：配置集中解析，依赖显式注入

这是所有“混乱”的根源。如果你的代码里，到处都是 os.Getenv(“DB_HOST”)，那你的项目已经走在了通往地狱的路上。

反模式：

在某个业务函数的深处，为了连一下 Redis，临时去读环境变量。这使得你的函数与外部环境强耦合，极难进行单元测试。

第一天原则：

在 main 函数中，一次性完成所有配置的解析和校验，然后通过构造函数，将“配置好”的依赖（如数据库连接池），以“接口”的形式，显式地注入到需要的服务中。

【Go 代码实战】

// https://go.dev/play/p/CrGDShmoFFJ
package main

import (
    "context"
    "database/sql"
    "fmt"
    "log"
    "net/http"
    "os"

    _ "github.com/lib/pq"
)

type Config struct {
    DatabaseURL string
    ListenAddr  string
}

func loadConfig() Config {
    dbURL := os.Getenv("DATABASE_URL")
    if dbURL == "" {
        log.Fatal("DATABASE_URL is not set")
    }
    return Config{
        DatabaseURL: dbURL,
        ListenAddr:  ":8080",
    }
}

type UserRepo interface {
    GetUser(ctx context.Context, id int) (string, error)
}

type PostgresUserRepo struct {
    db *sql.DB
}

func (r *PostgresUserRepo) GetUser(ctx context.Context, id int) (string, error) {
    var name string
    err := r.db.QueryRowContext(ctx, "SELECT name FROM users WHERE id=$1", id).Scan(&name)
    return name, err
}

func NewPostgresUserRepo(db *sql.DB) *PostgresUserRepo {
    return &PostgresUserRepo{db: db}
}

type Server struct {
    repo UserRepo
}

func NewServer(repo UserRepo) *Server {
    return &Server{repo: repo}
}

func (s *Server) HandleGetUser(w http.ResponseWriter, r *http.Request) {
    name, err := s.repo.GetUser(r.Context(), 1)
    if err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
    fmt.Fprintf(w, "User: %s", name)
}

func main() {
    cfg := loadConfig()

    db, err := sql.Open("postgres", cfg.DatabaseURL)
    if err != nil {
        log.Fatalf("failed to connect to database: %v", err)
    }
    defer db.Close()

    repo := NewPostgresUserRepo(db)
    server := NewServer(repo)

    http.HandleFunc("/user", server.HandleGetUser)
    log.Printf("Server starting on %s", cfg.ListenAddr)
    log.Fatal(http.ListenAndServe(cfg.ListenAddr, nil))
}

这样一来，你的业务代码将变得极其纯粹，不依赖任何全局状态，测试时也可以轻松地 Mock 掉 UserRepo 接口。

原则二：为可观测性而设计：结构化日志与 Metrics

“不就是打个日志吗，fmt.Println 走起！”——这是毁掉一个项目最快的方式。

反模式：

遇到错误，直接 log.Printf(“Error: %v”, err)。当线上出现几万条这样的日志时，你根本无法进行聚合、告警和趋势分析。

第一天原则：

从第一天起，就引入结构化日志（如 log/slog 或 zap）。将所有关键信息（如 user_id, trace_id）作为独立的字段打印。同时，为关键业务指标（如缓存命中率、数据库查询延迟）埋入 Metrics。

【Go 代码实战】

// https://go.dev/play/p/h4_8a4nzCFx
package main

import (
    "log/slog"
    "net/http"
    "os"
    "time"

    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
    cacheHits = prometheus.NewCounter(prometheus.CounterOpts{
        Name: "myapp_cache_hits_total",
        Help: "Total number of cache hits.",
    })
    dbQueryDuration = prometheus.NewHistogram(prometheus.HistogramOpts{
        Name:    "myapp_db_query_duration_seconds",
        Help:    "Histogram of database query durations.",
        Buckets: prometheus.DefBuckets,
    })
)

func init() {
    prometheus.MustRegister(cacheHits, dbQueryDuration)
}

func handleRequest(w http.ResponseWriter, r *http.Request) {
    logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))

    logger.Info("handling request", "method", r.Method, "path", r.URL.Path, "remote_addr", r.RemoteAddr)

    cacheHits.Inc()

    start := time.Now()
    time.Sleep(100 * time.Millisecond)
    duration := time.Since(start)
    dbQueryDuration.Observe(duration.Seconds())

    logger.Info("request handled successfully", "duration_ms", duration.Milliseconds())
    w.WriteHeader(http.StatusOK)
}

func main() {
    http.HandleFunc("/", handleRequest)
    http.Handle("/metrics", promhttp.Handler())

    log.Println("Server starting on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

有了结构化日志和Metrics的加持，你的系统不再是一个“黑盒”。通过 Grafana 和 VictoriaLogs，你可以清晰地看到它的每一个内部状态，问题定位速度提升 10 倍。

原则三：永不启动一个你不知道如何停止的 Goroutine

这是 Dave Cheney 反复强调的血泪教训。一个失控的 Goroutine，就是一个内存炸弹。

反模式：

go doSomething()。然后呢？它什么时候结束？如果它卡住了怎么办？

第一天原则：

任何一个需要长久运行的 Goroutine，都必须接受一个 context.Context 参数，并在 select 中监听 ctx.Done()。将所有后台 Goroutine 的生命周期，与你的应用程序生命周期绑定。

【Go 代码实战】

// https://go.dev/play/p/Fi1JUZfs4E-
package main

import (
    "context"
    "log"
    "os"
    "os/signal"
    "syscall"
    "time"
)

func worker(ctx context.Context, id int) {
    ticker := time.NewTicker(1 * time.Second)
    defer ticker.Stop()

    log.Printf("Worker %d started", id)
    for {
        select {
        case <-ticker.C:
            log.Printf("Worker %d is doing work", id)
        case <-ctx.Done():
            log.Printf("Worker %d is shutting down...", id)
            return
        }
    }
}

func main() {
    ctx, cancel := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
    defer cancel()

    go worker(ctx, 1)

    <-ctx.Done()

    log.Println("Main application shutting down.")
    time.Sleep(100 * time.Millisecond)
}

这样，你的应用就可以实现优雅停机（Graceful Shutdown），在 k8s 环境中滚动更新时，不会丢失任何正在处理的数据。

原则四：为可测试性而设计，构建你的“数据靶场”

在复杂的业务系统中，最难测试的不是“Happy Path”，而是各种千奇百怪的“Unhappy Paths”。

第一天原则：

为你的核心业务逻辑，构建独立的“数据生成器（Data Generators）”和“数据接收器（Sinks）”。在测试中，用内存中的模拟实现（Mocks）替换掉真实的外部依赖，从而能 100% 控制输入和验证输出。

【Go 代码实战】

// https://go.dev/play/p/NBsxpVE84Zb
package main

import (
    "context"
    "fmt"
    "sync"
    "testing"
)

type Order struct { ID int }

type OrderNotifier interface {
    Notify(ctx context.Context, order Order) error
}

type OrderProcessor struct {
    notifier OrderNotifier
}

func NewOrderProcessor(notifier OrderNotifier) *OrderProcessor {
    return &OrderProcessor{notifier: notifier}
}

func (p *OrderProcessor) Process(ctx context.Context, order Order) error {
    return p.notifier.Notify(ctx, order)
}

type MockNotifier struct {
    mu        sync.Mutex
    Notified  []Order
    ShouldErr bool
}

func (m *MockNotifier) Notify(ctx context.Context, order Order) error {
    m.mu.Lock()
    defer m.mu.Unlock()
    if m.ShouldErr {
        return fmt.Errorf("mock notifier failed")
    }
    m.Notified = append(m.Notified, order)
    return nil
}

func TestOrderProcessor_Success(t *testing.T) {
    mockNotifier := &MockNotifier{}
    processor := NewOrderProcessor(mockNotifier)
    order := Order{ID: 1}
    err := processor.Process(context.Background(), order)

    if err != nil {
        t.Errorf("expected no error, got %v", err)
    }
    if len(mockNotifier.Notified) != 1 || mockNotifier.Notified[0].ID != 1 {
        t.Errorf("notifier was not called correctly")
    }
}

遵守该原则后，你的单元测试将变得极快、极度稳定，并且能够 100% 覆盖所有你能想到的成功和失败分支。

原则五：防御性编程，构建你的“代码防火墙”

不相信任何外部输入。这是所有安全系统的第一性原理。

第一天原则：

在数据的入口处（如 HTTP Handler、gRPC Server），对所有传入的数据进行严格的、显式的校验（Validation）。只有通过了“安检”的干净数据，才能被允许进入系统的核心领域。

【Go 代码实战(不完全示例)】

package main

import (
    "encoding/json"
    "fmt"
    "net/http"
    "net/mail"
)

type CreateUserRequest struct {
    Username string json:"username"
    Email    string json:"email"
    Age      int    json:"age"
}

func (r *CreateUserRequest) Validate() error {
    if len(r.Username) < 3 || len(r.Username) > 20 {
        return fmt.Errorf("username length must be between 3 and 20")
    }
    if _, err := mail.ParseAddress(r.Email); err != nil {
        return fmt.Errorf("invalid email format: %w", err)
    }
    if r.Age < 18 {
        return fmt.Errorf("user must be at least 18 years old")
    }
    return nil
}

func HandleCreateUser(w http.ResponseWriter, r *http.Request) {
    var req CreateUserRequest
    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
        http.Error(w, "Invalid request body", http.StatusBadRequest)
        return
    }

    if err := req.Validate(); err != nil {
        http.Error(w, err.Error(), http.StatusBadRequest)
        return
    }

    // processValidatedRequest(req) ...
    w.WriteHeader(http.StatusCreated)
}

这种防御可以让你的核心业务逻辑变得极其纯粹和安全，不再需要处理各种脏数据和边界情况。

注：如果是服务器，外部(甚至是内部其他服务的)请求的速度也可能是一种“安全威胁”。因此无论是通过中间件，还是代码自行实现，限速机制是必不可少的。

原则六：错误包裹与类型化错误，让错误自己开口说话

一个好的错误信息，应该像一份精准的“尸检报告”，而不是一句无意义的“他死了”。

第一天原则：

在错误产生的最底层，用 fmt.Errorf(“…: %w”, err) 详细包裹上下文。对于可预期的业务异常，定义成自定义的“类型化错误（Typed Errors）”，让上层逻辑可以通过 errors.As 进行精准的判断和处理。

【Go 代码实战(不完全示例)】

package main

import (
    "errors"
    "fmt"
    "net/http"
)

type ErrDuplicateUser struct { Email string }

func (e *ErrDuplicateUser) Error() string {
    return fmt.Sprintf("user with email %s already exists", e.Email)
}

func RegisterUser(email string) error {
    // 模拟数据库层返回一个已知类型的错误
    if email == "test@example.com" {
        return &ErrDuplicateUser{Email: email}
    }
    return fmt.Errorf("db connection failed: %w", errors.New("timeout"))
}

func HandleRegister(w http.ResponseWriter, r *http.Request) {
    err := RegisterUser("test@example.com")
    if err != nil {
        var dupErr *ErrDuplicateUser
        if errors.As(err, &dupErr) {
            http.Error(w, dupErr.Error(), http.StatusConflict)
        } else {
            // 对于未知的底层错误，只打日志，不暴露给用户
            slog.Error("failed to register user", "error", err)
            http.Error(w, "Internal server error", http.StatusInternalServerError)
        }
        return
    }
    w.WriteHeader(http.StatusCreated)
}

这样处理后，你的错误处理逻辑变得极其清晰和健壮，业务异常可以被优雅地反馈给用户。

原则七：接口定义在消费侧，实现“最小化契约”

这是 Go 语言最精髓、也最反直觉的一条哲学。

第一天原则：

永远不要在“定义侧”声明臃肿的接口。而是在“消费侧”，根据你真正需要的功能，定义一个只包含 1-2 个方法的“小接口”。

【Go 代码实战（不完全示例）】

// --- cache/cache.go ---
package cache
type BigCache struct {}
func (c *BigCache) Get(key string) (string, error) { /* ... */ }
func (c *BigCache) Set(key, val string) error     { /* ... */ }

// --- user/service.go ---
package user
import "fmt"
// 我们在 user 包里，只定义我们真正需要的小接口
type Getter interface {
    Get(key string) (string, error)
}
type UserService struct {
    cache Getter // 依赖的是小接口，而不是具体的 BigCache
}
func (s *UserService) GetUserName(id int) (string, error) {
    return s.cache.Get(fmt.Sprintf("user:%d", id))
}

示例代码中，你的 UserService 彻底与 BigCache 的具体实现解耦。在测试时可以极其轻松地传入 Mock 对象。

小结：架构的本质，是与未来的自己对话

看完上述的七条原则，你是否发现所有这些“第一天原则”都指向了一个共同的核心：可维护性（Maintainability）。

你在项目第一天偷的每一个懒，都会在未来的某一个深夜，变成一颗狠狠炸伤你或你同事的“技术地雷”。架构的本质，不是选择一个多么牛逼的框架，而是与未来的自己、未来的同事进行一场清晰、友好的对话。

关掉这篇文章，打开你手头那个最新的项目。看看这 7 条原则，你触犯了哪几条？是时候，给你的代码库做一次“体检”了。

今日互动探讨：

在你过去的 Go 项目中，踩过哪些因为早期“野蛮生长”而导致的设计大坑？除了这 7 条，你还有哪些“压箱底”的项目启动最佳实践？

欢迎在评论区分享你的血泪史与独家心法！

还在为写 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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/04/23/hashicorp-founder-admits-go-is-alive-thanks-to-ai

大家好，我是Tony Bai。

今天是世界读书日，在同款公众号文章的文末我将送出两个价值 99 元的《从 0 开始构建 Agent Harness》专栏的免费兑换码，欢迎大家点击这里积极留言参与！

在技术圈的江湖里，总有那么几位“扫地僧”级别的人物。他们的一言一行，足以引发整个行业的地震。Mitchell Hashimoto，正是其中之一。

作为 HashiCorp 的创始人，曾连续12年，一手使用Go 缔造了Consul、Nomad、Terraform、Vagrant、Vault 等一系列云原生基础设施与Devops“神器”以及Ghostty Terminal (使用 Zig )的他，被无数开发者奉为“云基础设施时代教父级的人物”。

但在 Go 社区，Mitchell 的形象却颇具争议。因为他曾在公开场合不止一次地表达过对 Go 语言的失望，甚至抛出过“Go has no place anymore”（Go 已无立足之地）这样的“暴论”。

然而，就在最近，这位曾经的“Go 社区的争议人物”，却在 X 平台上发表了一篇 180 度大转弯的“认错”长推，瞬间引爆了整个技术圈，获得了超过 21 万的阅读量。

他写道：

“我又开始写 Go 了……‘等等，我以为你说过 Go 已经没有位置了？’我错了。”

“我错的原因，主要是因为 AI 智能体（Agent）在 Go 语言上的生产力高得惊人。我不会把其他语言扯进来，因为我不想喂饱那些螃蟹（暗指 Rust 社区）。”

是什么，让这位顶级大神发生了如此戏剧性的转变？

今天，我们就来深度扒开 Mitchell 的这篇“忏悔录”，看看在 AI Agent 席卷一切的时代，Go 语言那些曾被我们疯狂吐槽的“缺点”，是如何摇身一变，成为最顶级的“超能力”的。

惊天反转：“糟糕的人体工程学”，竟是完美的“机器工程学”

Mitchell 在推文中，首先就点出了一个极其“讽刺”的现象：

“这很有趣，因为 Go 的很多 CLI 工具，比如 go doc 和 gopls，它们糟糕的人体工程学（shitty ergonomics）……竟然被 Agent 完美地规避了。不仅如此，讽刺的是，它们对 Agent 来说简直是天赐之物。”

这句话，堪称整篇推文的点睛之笔。

如果你是一个有经验的 Go 开发者，你一定吐槽过 go doc 的简陋，或者早期 gopls 的各种不智能。相比于 Rust 的 rust-analyzer 那种极其强大的类型推断和代码补全，Go 的工具链显得既“笨”又“直白”。

但在 AI Agent 的世界里，这种“笨拙”，恰恰成了最顶级的优点！

Mitchell 指出，他现在根本不需要给 Agent 写任何复杂的 Skill。只需要在 AGENTS.md 里写一句极其简单的指令：“想找 API 或者调用者？去用 gopls。”

Agent 就能利用 gopls 提供的底层 LSP（语言服务器协议）接口，以极低的 Token 成本，精准地找到接口的实现、方法的定义，以及所有的调用关系。

另一位开发者在评论中也补充道：

“我们一直抱怨 Go 的啰嗦（verbosity），结果证明这恰恰是 LLM 最喜欢的。它们能清晰地读懂意图，而且工具链（如 go doc）给了它们足够的上下文，让它们第一次就能写出能跑通的代码。”

看懂了吗？

那些曾经被人类程序员嫌弃的“机器友好”的接口，在 AI Agent 这个“硅基程序员”面前，摇身一变成了最高效、最廉价的沟通方式。

我们过去追求的“CLI 人体工程学”，在 AI 时代，正在被“Agent 机器工程学”所降维打击。

王者归来：当“无聊”成为 AI 的最佳温床

Mitchell 的“认错”，不仅仅是因为工具链的意外适配。更深层次的原因，在于 Go 语言本身的“无聊”哲学。

在另一场由 OpenAI 创始人引发的“Go vs Rust”论战中，我们已经探讨过这个观点：

Go 语言极简的语法、强制的 gofmt 格式化、以及“万物皆 for 循环”的单一表达方式，使得所有 Go 代码库看起来都像是一个模子里刻出来的。

这种极度的“同质化”，对于基于概率预测的 AI Agent 来说，简直就是天堂。

AI 在生成 Go 代码时，不需要去猜测这个项目是函数式风格还是面向对象风格，不需要去处理复杂的生命周期和所有权问题。它只需要遵循那套刻在骨子里的“Go Way”，就能生成出八九不离十的、能跑通的代码。

评论区里，HashiCorp 的前同事现身说法：

“我当年就是看到 HashiCorp 在用 Go 才入坑的。你今天的这篇帖子，完美地解释了为什么我最近又回到了 Go 的怀抱。”

简单、可预测、没有魔法。 这些在人类极客眼中可能是“缺点”的特质，在 AI Agent 眼里，却成了最宝贵的“确定性”。

终极答案：Go + Zig，基础设施的“黄金搭档”

当然，Mitchell 也并非无脑吹捧 Go。作为一个顶级的开发者，他清醒地认识到 Go 的边界。

当他需要编写一个“可移植的、能轻松嵌入各种生态系统”的底层库时，他并没有选择 Go，而是选择了 Zig。

“对我来说，重要的是可移植性。我正在写一个必须能轻松嵌入各种生态系统的通用库。一个独立的、不依赖 libc、没有操作系统原语要求、能说 C ABI、并且只有 100KB 大小的库，是一个很容易推销的方案。”

在这里，Mitchell 亮出了他的答案：Go + Zig。

• Go：负责上层的、高并发的业务逻辑和网络调度。
• Zig：负责底层的、需要极致性能、零依赖、跨平台 C ABI 兼容的核心组件。
• CGO：通过 Zig 强大的交叉编译能力，将 Go 与底层 C-ABI 组件的胶水成本降到最低。

这套组合拳，既享受了 Go 无与伦比的开发效率和并发模型，又利用了 Zig 对底层的极致压榨能力，同时还避开了原生 CGO 的种种编译噩梦。

这或许是比“Go vs Rust”之争，更具前瞻性和实操价值的“版本答案”。

英雄所见略同：Pandas 之父的“痛苦告别”

如果说 Mitchell Hashimoto 的“回归”还带有一丝 云原生以及DevOps 创始人的恋旧情结，那么另一位顶级大神——Pandas 库的创始人、数据科学界的“教父级”人物 Wes McKinney——的2026表态，则更像是一封写给 Python 的“分手信”，充满了痛苦、不舍，但又极其决绝。

就在 Mitchell 的推文引发热议的同时，有人在评论区挖出了 Wes McKinney 今年年初的一篇极具前瞻性的博文《从人类工程学到智能体工程学》。

在这篇文章里，Wes McKinney 抛出了一个极其震撼的开场白：

“我最近用 Go 写了很多新软件。但问题是，我这辈子其实一行 Go 代码都没写过。这到底是怎么回事？”

答案，同样是 AI Agent。

作为一个将毕生心血都奉献给了 Python 数据科学生态的巨匠，Wes McKinney 坦言，当软件的“主要作者”从人类变成 AI 时，我们评判一门编程语言优劣的标准，发生了根本性的改变。

“人类工程学（Human Ergonomics）的重要性正在急剧下降。Python 对人类来说极其愉快和高效，但当 Agent 替你写所有代码时，这个好处就显得无足轻重了。”

他用一种近乎“残忍”的视角，剖析了 Python 在 AI Agent 时代的三个致命缺陷：

1. 缓慢的编译-测试循环：Agent 编译和测试的频率比人类高出一到两个数量级。Python 缓慢的测试启动和依赖安装，对 Agent 来说是一种“惩罚”。
2. 痛苦的软件分发：Agent 需要大量自包含的、无依赖的二进制工具。而 Python 拖着一个沉重的解释器，感觉就像“我们当年拼命想摆脱的 Java 虚拟机（JVM）”。
3. 性能与内存的短板：这些在人类开发时可以容忍的问题，在 Agent 24 小时高强度运行时，会被无限放大。

那么，AI Agent 时代的“赢家”是谁？

Wes McKinney 给出了和 Mitchell Hashimoto 几乎一模一样的答案：Go。当然在数据科学以及人工智能的基础设施层面，Wes McKinney认为 Rust 也将会占据着越来越重要的地位。

因为它们解决了最关键的三个问题：

• 无痛构建静态二进制文件。
• 极速、确定性的构建过程。
• 精简的资源占用和出色的运行时性能。

他甚至更进一步指出，由于 Go 拥有比 Rust 快得多的编译时间，在 Agent 高频迭代的场景下，Go 甚至比 Rust 更具优势。

“我依然深爱着 Python，并为我们建立的生态系统感到自豪。但很明显，鉴于 Agent 循环带来的生产力优势，我和业界的大部分人，将会写越来越少的 Python，转而拥抱 Go 和其他现代编译语言。”

一个为 Python 奋斗了近 20 年的灵魂人物，最终为了 AI，选择了自己从未写过的 Go。

这已经不是简单的技术选型，这是一场关于“工程师生存法则”的深刻变革。

英雄惜英雄：一场关于“回归”的集体狂欢

Mitchell 的这篇“认错”长文，像一声号角，引来了无数在 Go 与其他语言之间摇摆的开发者的共鸣。

Bun 的创始人 Jarred Sumner 激动地在评论区留言：“我想看看你到底在搞什么！”（Mitchell 回复：“我早点联系你！”）

一位前 Vercel 工程师更是直言：“老哥你终于兜了一圈又回来了！”

当然也有一些开发者表示这也许是Mitchell的“幻觉”或“偏见”，一位开发者(显然不是很熟悉 Mitchell 的开发过往)写道：

“也许你只是比 Zig 更不习惯 Go，所以你注意到的 Go 的问题更少。而且你已经是 Zig 的专家了，用它提升的空间不大了(想学习一下新的编程语言)。LLM 让你看到在你不懂的领域(指Go)正确率是 100%，但在你懂 60% 的领域(指Zig)，只对了 60%”。
（Mitchell 则毫不客气地回怼：“我写了 12 年全职的、纯粹的 Go。我的判断力很可靠。”）

这场大讨论，最终演变成了一场关于“回归 Go”的集体狂欢。

小结：在 AI 时代，重新审视“简单”的价值

Mitchell Hashimoto 的故事，是 AI 时代软件工程演进的一个完美缩影。

一个曾经因为 Go 的“不够底层”、“人体工程学差”而选择离开的顶级大神，最终又因为 AI Agent 的出现，重新发现了这门语言在“机器工程学”上的巨大价值。

这提醒我们所有技术人：对一门语言的评判，永远不能脱离其所处的时代背景和生产力工具。

在人类手搓代码的时代，我们追求的是表达力的丰富和语法的灵巧。

而在 AI 自动生成的时代，简单、可预测、无歧义、易于机器理解，反而成了最稀缺的“黄金法则”。

Go 语言的缔造者们，在十几年前就用近乎偏执的克制，为我们埋下了一颗时间的种子。

直到今天，在 AI 的催化下，这颗种子，终于长成了参天大树。

资料链接：

• https://x.com/mitchellh/status/2046319366489407803
• https://wesmckinney.com/blog/agent-ergonomics/

今日互动探讨：

在 AI 编程的浪潮中，你是否也像 Mitchell 一样，重新审视了自己对某门语言的看法？你认为在 AI Agent 眼里，最“友好”和最“劝退”的语言分别是什么？

欢迎在评论区分享你的观点！

世界图书日特别福利：一本定义未来的“活书”

今天（4月23日）就是世界图书日。

在这个属于知识与智慧的节日里，与其被动地阅读别人写的书，不如我们亲手来“写”一本定义未来的“书”——构建一个属于你自己的 AI Agent Harness。

Mitchell Hashimoto 和 Wes McKinney 的故事告诉我们，AI Agent 正在成为这个时代最强大的生产力杠杆。而驾驭这头巨兽的核心，不在于你会背多少 Prompt，而在于你是否懂得如何为它构建一个坚不可摧的“驾驭系统（Harness）”。

为了庆祝我的全新极客时间专栏 《从 0 开始构建 Agent Harness》 上线，并感谢大家一直以来的支持，我将拿出 2 个免费的专栏兑换码送给大家！

参与方式：

关注本公众号，并在本文的评论区留言，聊一聊：“在 AI Agent 时代，你认为一个程序员最不可被替代的核心技能是什么？为什么？”

我将在 72 小时后，从所有精选留言中，挑选 2 位最深刻、最走心的思考，每人赠送一份价值 99 元的《从 0 开始构建 Agent Harness》专栏兑换码。

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

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/04/21/why-we-are-building-agent-harness-from-scratch

大家好，我是Tony Bai。

今天想和大家分享一个好消息：我筹备已久的极客时间专栏 《从0 开始构建 Agent Harness》 于昨日(2026.4.20)正式上架了。

在这个各种 AI 应用框架满天飞、“几行 Python 代码就能跑起一个智能体”的时代，很多朋友可能会问：“Tony，大家都在用现成且免费的轮子，你为什么还要花这么大的精力，甚至专门开一个 24 讲的专栏，带着大家用 Go 语言从零去手写一个底层的 Agent Harness 引擎？”

借着专栏上架的机会，我想和大家聊聊，我是如何看待当前 AI 应用开发的，以及为什么我坚定地认为，现在是时候撕开框架的黑盒，回归底层的 Harness（驾驭工程）了。

拐点已至：被框架掩盖的“失控”

如果你在一年多前开发过 AI Agent，你大概率深度使用过 LangChain、AutoGen 等框架。在那个大模型（如 GPT-3.5 时代）推理能力还比较薄弱的时期，我们需要框架来帮模型做意图路由、做任务拆解，框架扮演的是一个“事无巨细的微管家”。

但现在的技术发展，已经到了一个明确的“拐点”。

随着 Claude Sonnet 4.6/Opus 4.7、GPT-5.4、Gemini 3.1 Pro 等前沿模型的问世，模型原生已经具备了极其恐怖的逻辑规划和工具调用（Function Calling）能力。这时候，如果你尝试把基于传统框架拼接出来的 Agent 投入到真实的生产环境（比如让它去排查线上日志、或者做复杂的代码重构），问题往往接踵而至：

• 上下文雪崩：Agent 读取了一个 3000 行的日志文件，框架没有任何底层的内存压缩机制，大模型 API 直接抛出 400 Token limit exceeded，任务当场中断。
• 陷入死循环：Agent 遇到一个顽固的报错，连续 10 次执行了错误的 bash 命令，毫无察觉地在原地打转，直到把你的账户余额耗尽。
• 失控的破坏力：你赋予了它执行本地 Shell 的权限，但在某次幻觉中，它试图执行不可逆的删除操作，而底层的框架根本没有提供可靠的挂起拦截机制。

这些令人“绝望”的瞬间让我意识到：单纯靠堆砌 Prompt 或者调用更高层级的应用框架，是永远无法构建出工业级 Agent 的。我们把最核心的控制权统统交给了不可见的黑盒。

什么是 Harness？为什么要独立研究它？

在剖析了近期震撼业界的顶级原生智能体（如 Claude Code、开源神作 OpenClaw、以及自带进化能力的 Hermes等）的工作机制后，我看到了一个不可逆转的趋势：

传统的框架层正在加速坍塌，作为独立工程研究的 Harness（驾驭工程）正在全面崛起。

什么是 Harness？简单来说，如果把大模型比作 CPU，把上下文（Context Window）比作极其昂贵的内存，那么 Harness 就是为这个 CPU 打造的微型操作系统（OS）。

Harness 不去干涉大模型的思考，它的核心职责极其底层且硬核：

• 如何在濒临 OOM（内存溢出）的边缘，像垃圾回收器一样优雅地进行上下文阶梯压缩？
• 如何在 Agent 陷入死循环时，像系统级中断一样注入强提醒，拉回它的注意力？
• 如何在它试图执行高危命令前，挂起底层的协程，等待人类在飞书里的审批？
• … …

我花这么大的精力带大家手写 Harness，就是因为现在的难点，早就不是“怎么让大模型输出 JSON”，而是“怎么在物理层面驾驭大模型的破坏力与失控”。

AI 应用的新阶段：Agent 正在成为一类完整的 Application

当我们拥有了一个健壮的 Harness 之后，我们对 AI 应用的认知也会随之重塑。

以前，AI 只是应用里的一个 Feature（功能），比如挂在网页右下角的一个聊天框。

但今天，当你把一个配置了特定 System Prompt 和专属 Skills（技能 SOP）的 Harness 引擎，丢进某一个特定的业务目录里运行时，这个 Agent 本身，就成了一个完整的 Application。

当然，AI 应用的形态是多元的，Agent 并非唯一的范式——AI 作为功能模块嵌入传统产品的场景依然大量存在。

但对于那些以自主完成复杂任务为核心价值的应用而言，”AI App = AI Agent”这个等式正在越来越多的场景下成立。我们不再是写满是 CRUD 的业务代码，我们是在为不同形态的智能体（如：编码Agent、自动化运维 Agent、自动化 CR 助手等）编写底层”物理定律”。

极简哲学：为什么手写能带来认知跃迁？

相较于一两年前的开发模式，今天顶尖的 Agent 项目展现出了一种令人拍案叫绝的“返璞归真”。

以 OpenClaw 为代表的新一代驾驭工程，抛弃了复杂：

• 最简工具法则：不再堆砌几十个专用 API 导致上下文膨胀，只给模型暴露 Read、Write、Edit 和 Bash 等基础原语工具。让大模型用自然语言去驱动底层的操作系统。
• 状态外部化：彻底抛弃内存里人类不可读的复杂状态机。强制大模型把宏观计划写在 PLAN.md 里，把微观进度写在 TODO.md 里。把每天的记忆变成了普通的文本文件，不仅实现了零成本的断电续传，更让人类可以随时在 IDE 里修改文件，实现最优雅的人机协同（Human-in-the-loop）。
• … …

如果你不亲自手写一遍这个引擎，你永远只能在外围惊叹这些设计，而无法将其转化为自己解决复杂业务问题的武器。

专栏的策划：从骨架到全息监控

为了把这些前沿的理念落地，我没有选择纸上谈兵。我决定带着大家用 Go 语言（云原生时代构建基础设施的最佳语言），手敲一个名为 go-tiny-claw 的工业级引擎。

我们的旅程不走捷径，专栏规划了极具层次感的 24 讲大纲：

细心的朋友会发现，除了核心引擎和工具链，我在专栏的后期（模块五），花了不小的篇幅去写 成本追踪（Cost Tracker）、链路回放（Tracing） 和 自动化跑分（Benchmark）。

之所以加入这些章节，是出于对 AI Agent 工程化落地 的深切体悟。

在企业里，如果一个智能体没有“仪表盘”，你连它跑一次花了多少美金都不知道；如果没有 Tracing 的 JSON 树，当任务在半夜崩溃时，你面对满屏黑盒日志根本无从 Debug；如果没有自动化的 Benchmark，你改了一行提示词，都不知道系统是变聪明了还是变笨了。

把玄学变成工程学，这是从“玩具”走向“工业级”的必经之路。

抛砖引玉：拥抱前沿，共同进化

坦白地说，Harness Engineering（驾驭工程）是一个极其前沿、且目前在业界依然处于野蛮生长和快速迭代的阶段。

无论是开源的 OpenClaw 和 Hermes ，还是Claude Code 的非官方流出，又或是学术界的最新研究论文，都在不断刷新着我们对 Harness 架构的认知上限。

这个专栏定位是 Agent Harness 的概念入门与环环相扣的底层实战。专栏里的每一讲（比如基于双重降级的上下文掩码压缩、或者是错误自愈模板的注入），其实都值得单独抽出来，作为更深入的课题去研究。

我就算是为大家“抛砖引玉”了。

以专栏中提到的 “Session Context 阶梯压缩” 为例。在专栏里，为了保持架构的极简易懂，我们采用了高效的字符级“远期全量掩码”与“近期掐头去尾截断”策略。

但这远非终点。

大家在学习后，完全可以去查阅 Claude Code 源码中更多层级的上下文折叠思路，或者探索多智能体（Multi-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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/04/18/ollama-from-open-source-hero-to-community-enemy

大家好，我是Tony Bai。

两年前，在本地大模型的蛮荒时代，Ollama 曾如一道神光，照亮了无数普通开发者的探索之路。

凭借那句魔咒般的 ollama run llama3，它以一种近乎“降维打击”的优雅，将普通人与本地 AI 之间的天堑夷为平地。

一时间，Ollama 被盛赞为“本地 AI 的 Docker”、“开源精神的典范”，几乎成了无数技术布道者口中的“开源英雄”。

但就在几天前，一篇名为《本地大模型生态系统不再需要 Ollama》的文章，在技术社区 Hacker News 上，引发了一场“社区公审”。

文章详细罗列了 Ollama 在享受了社区的赞誉之后，犯下的种种“罪行”：从对核心依赖 llama.cpp 长达 400 多天的“选择性遗忘”，到试图用私有模型格式“绑架”用户，再到其背后若隐若现的“VC 商业化”套路……

一夜之间，Ollama 的形象从“屠龙少年”，变成了那条它曾经挑战的“恶龙”。

今天，我们就来深度复盘这场顶级社区的大讨论，看看这位曾经的“开源英雄”，究竟是如何一步步走向“社区公敌”的深渊的。

第一宗罪：对生身之父的“背叛”与“除名”

Ollama 之所以能如此快速地在各种平台上运行大模型，其背后最大的功臣，是一个名为 llama.cpp 的 C++ 开源库。llama.cpp 是真正负责模型推理的底层引擎。

Ollama 的 v0.0.1 版本，在其 README 中曾明确写道：“一个用 Go 编写的快速推理服务器，由 llama.cpp 驱动。”

Ollama 的本质，是一个基于 llama.cpp 构建的、优化了用户体验的“包装器（Wrapper）”。

然而，随着 Ollama 的声名鹊起，llama.cpp 的名字，却在其官网和宣传中，被刻意地、系统性地抹去了。

在 Hacker News 的帖子中，有用户愤怒地指出：

“这根本不是开源礼仪的问题。MIT 协议只有一个核心要求：包含版权声明。Ollama 没有做到。”

“社区注意到了。GitHub Issue #3185 在 2024 年初就被提出，要求 Ollama 遵守协议。这个 Issue 在 400 多天里，没有得到任何维护者的回应。”

直到社区忍无可忍，发起了 PR，Ollama 的联合创始人才最终在 README 的最底部，加上了一行极其微小的致谢：“llama.cpp 项目由 Georgi Gerganov 创建。”

这种对核心上游项目近乎“羞辱性”的冷处理，被社区视为一种赤裸裸的“背叛”，激怒了所有信奉开源精神的开发者。

第二宗罪：用“私有格式”构建“数据监狱”

比忘记致谢更让开发者无法容忍的，是 Ollama 为了“锁定用户”，而精心设计的私有化模型存储格式。

如果你用过 Ollama，你一定经历过这样的困惑：

你用 ollama pull 下来的模型文件，被存储在你的 Home 目录下，文件名是一串毫无意义的哈希值。你根本无法将这个 GGUF 文件，直接分享给其他工具（比如 LM Studio 或 Jan）使用。

Hacker News 的一位用户一针见血地指出了这个设计的“阴险”之处：

“我停止使用 Ollama 的原因就在于此。我能理解他们可能是为了做去重（Deduplication），但这使得我无法与其他工具共享同一个模型。每个工具都只能指向它自己的文件。无论他们的意图如何，这都在客观上，让你极难尝试其他工具。”

更糟糕的是，Ollama 会在下载模型时，对原始的 GGUF 文件进行一些“魔改”，并使用自己的一套私有配置。这导致了另一个灾难：性能下降。

有人在评论中分享道：“我最近开始使用 Jan，然后用 llama.cpp 和本地的 Ollama 跑同一个模型，llama.cpp 的速度明显更快。”

用更差的性能、更封闭的格式，换取所谓“简单”的用户体验。这背后，是典型的“建立围墙花园”的商业化思维。

第三宗罪：“VC 死亡陷阱”的经典复刻

Ollama 为什么要这么做？

一位用户在评论中扒出了 Ollama 创始团队的“前科”，让所有人恍然大悟。

“Ollama 是一家由 Y Combinator 支持的创业公司，其创始人之前构建了一个被 Docker 收购的 Docker GUI 工具。这个剧本太熟悉了：
1. 包装一个现有的开源项目，做一个用户友好的界面。
2. 建立用户基础，获得社区信任。
3. 融资，然后想办法商业化。
4. 最小化对上游的致谢，让产品看起来是自给自足的。
5. 创造锁定，用私有格式和哈希文件名，让用户无法迁移。
6. 推出闭源组件（GUI App）和云服务，开始收割。”

这套从 Docker 时代的 Kitematic 延续而来的“VC 死亡陷阱”，正在本地大模型领域被完美复刻。

社区的反击：大逃杀与“去 Ollama 化”

在这场社区的“公审”中，愤怒之余，开发者们也给出了大量极具建设性的“替代方案”。一场“去 Ollama 化”的大逃杀正在上演。

方案一：回归 llama.cpp 本身，王者归来

很多用户惊讶地发现，在他们唾弃 Ollama 的这段时间里，llama.cpp 自身已经进化成了一个极其强大的“完全体”。

它现在不仅自带了现代化的 Web UI（通过 llama-server），支持 OpenAI 兼容的 API，甚至还推出了“路由模式”，可以实现模型的“热插拔（Hot-swapping）”。

方案二：拥抱真正开放的“包装器”

社区推荐了大量同样易用，但秉持着真正开源精神的替代品，比如：

• LM Studio：自带强大的 GUI，底层使用 llama.cpp，暴露所有可调参数，支持任何 GGUF 模型，不搞“锁定”。
• Jan (jan.ai)：另一个开源的桌面应用，界面清爽，设计本地优先。
• llamafile：由 Mozilla 支持，可以将模型和 llama.cpp 本身打包成一个“单一可执行文件”，真正实现“一键启动”，且完全开放。

小结：当便利性遭遇开源精神

Ollama 的故事，是近年来开源商业化领域最值得深思的一个案例。

毫无疑问，Ollama 解决了本地大模型领域一个极其真实的痛点：极致的易用性（Ease of use）。它就像当年的 Docker，让无数普通人跨越了复杂的门槛。

但在追求极致 UX 的同时，它却似乎忘记了自己赖以生存的根基——那个由 Georgi Gerganov 等无数开源贡献者用爱发电构建起来的 llama.cpp 生态。

Hacker News 上的这场论战，并没有全盘否定 Ollama 的价值。但它向所有试图通过“包装开源”来构建商业帝国的创业者，提出了一个极其严肃的警告：

用户体验的简化，永远不能以牺牲“开放性”和对上游社区的“尊重”为代价。

你可以站在巨人的肩膀上，但你不能在站上去之后，假装那个巨人不存在。

作为开发者，我们享受着开源带来的巨大红利。但在选择工具时，除了便利性，我们或许也应该多一份清醒：去看看它的背后，是否隐藏着一个正在试图关上的“围墙花园”。

资料链接：

• https://news.ycombinator.com/item?id=47788385
• https://sleepingrobots.com/dreams/stop-using-ollama/

今日互动探讨：

你在使用 Ollama 时，是否也曾被它私有的模型管理方式所困扰？对于“包装开源”并进行商业化的模式，你是支持还是反对？

欢迎在评论区分享你的看法！

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

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

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

原「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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/04/17/tiobe-ranking-and-the-decline-of-rust-hype

大家好，我是Tony Bai。

过去几年，技术圈最热门的“猜谜游戏”之一，就是预测 Rust 什么时候能杀入 TIOBE 排行榜的前十。

这门被誉为“天选之子”的语言，连续多年霸榜 Stack Overflow“最受喜爱”的宝座，被微软、亚马逊等巨头奉为重写底层基础设施的“银弹”。所有人都觉得，它冲进前十，只是时间问题。

但就在最近，TIOBE 指数发布了 2026 年 4 月的最新排名。

榜单本身平平无奇，Rust 的排名甚至还从去年同期的 18 位微升到了 今年的16 位。

然而，TIOBE 的 CEO Paul Jansen 亲自撰写的一篇社论，却像一盆冷水，劈头盖脸地浇在了所有 Rustacean（Rust 开发者）的头上。

Paul Jansen 用极其明确的措辞，给这门甚至还没来得及摸到前十门槛的语言，提前下了一份“病危通知书”：

“Rust 的崛起显示出放缓的迹象。……它进入前十的梦想，现在看来比以前更加遥远了。”

这篇社论，瞬间引爆了全网的讨论。

无数 Rust 开发者感到匪夷所思，甚至有些愤怒：我们还没真正发力，你怎么就开始唱衰了？

这背后，到底是 TIOBE 对技术趋势的精准预判，还是这把统治了我们十几年的“认知标尺”，已经彻底失灵了？

今天，我们就来扒开这张榜单的底裤，看看在喧嚣的数据背后，Rust 的真实处境，究竟是怎样的。

官方的“诊断书”：Rust 的“阿喀琉斯之踵”

我们先来看看 TIOBE CEO Paul Jansen 的“诊断报告”。

他指出，Rust 在今年年初曾一度冲到历史最高排名第 13 位，但仅仅三个月后，就又跌回了第 16 位。

他给出的解释是：

“一个可能的解释是，尽管 Rust 能够生产出高效和安全的代码，但对于非专家程序员来说，它仍然难以学习。虽然专家们愿意投入时间去掌握这门语言，但更广泛的主流采用似乎面临着更大的挑战。”

这段话，精准地戳中了 Rust 社区最敏感、也最引以为傲的那根神经——陡峭的学习曲线。

为了追求极致的内存安全，Rust 发明了极其复杂的“所有权（Ownership）”和“借用检查（Borrow Checker）”系统。这套系统像一个极其严苛的导师，在你编译代码的每一个环节，都对你进行着灵魂拷问。

无数新手在入门 Rust 时，都会经历一段被称为“与编译器搏斗”的痛苦时期。

TIOBE 的观点很明确：这种“精英主义”的设计哲学，正在成为 Rust “出圈”的最大障碍。

榜单的原罪：用“百度指数”去衡量火箭科学

TIOBE 的诊断听起来似乎很有道理。但我们必须先问一个更底层的问题：TIOBE 指数，到底是个什么东西？

TIOBE 的排名，本质上是一个基于“搜索引擎查询量”的指标。它在全球 25 个主流搜索引擎上，统计包含 +” programming” 关键词的页面数量。

看懂了吗？这套诞生于 十多年前的评判标准，在 2026 年的今天，已经变得极其荒谬。

它衡量的是一门语言在公网上的“话题度”和“声量”，而不是它的“真实价值”和“商业应用”。

这就像用“微博热搜”的次数，去评判一位科学家的学术贡献一样可笑。

用这把“旧尺子”去衡量现代编程语言，会产生几个致命的认知偏差：

1. 越是难学、坑越多的语言，排名越高。

这恰恰是 TIOBE 逻辑最诡异的地方。Paul Jansen 一边抱怨 Rust 太难学，一边却忽视了，正是因为“难学”，新用户才会频繁地去 Google 搜索“Rust a lifetime that lives long enough”、“the trait Borrow is not implemented for String”这些令人抓狂的报错信息。

每一次“救命”的搜索，都在为 Rust 的 TIOBE 排名，贡献着宝贵的 KPI。

2. 越是成熟、生态完善的语言，排名越吃亏。

随着一门语言的成熟，它的文档会越来越完善，社区的最佳实践会沉淀下来。开发者遇到的问题，更多地会在官方文档、IDE 提示、或者小圈子的 Slack/Discord 里被解决，而不会产生大量的公开搜索。

没有问题，就没有搜索。没有搜索，就没有 TIOBE 排名。

3. TIOBE 无法衡量“生态位”的价值。

Rust 的江山在哪里？在 Linux 内核里(注：最近发布的Linux Kernel 7.0里，Rust已经正式转正了！)，在 Windows 的系统组件里，在 Cloudflare 的边缘网络里，在 Figma 的渲染引擎里，在那些对性能和安全要求达到极致的底层基础设施里。

这些领域的开发者，是金字塔尖的系统程序员。他们讨论问题，是在 GitHub Issue、Zulip 频道，而不是在 CSDN 上问“我的 &mut 为什么传不进去”。

Rust 的价值，深藏在那些不会产生大量公开搜索记录的、高壁垒的硬核场景里。而 TIOBE 的爬虫，可能永远也爬不到那里。

真实的版图：Rust 正在经历一场“青春期的烦恼”

扒开 TIOBE 的“障眼法”，我们该如何客观看待 Rust 在 2026 年的真实处境？

Rust 并没有“增长放缓”，它只是在经历一场必然的“出圈阵痛”。

任何一门新技术的发展，都会经历两个阶段：

1. 从 0 到 1 的“深耕期”：吸引最硬核、最狂热的一批早期用户，在特定的垂直领域里，将自己的核心优势打磨到极致。Rust 在“系统编程”领域，已经完美地完成了这个阶段。
2. 从 1 到 N 的“出圈期”：试图将自己的影响力，扩展到更广阔的领域，吸引更多的主流开发者。

Rust 现在正处于从阶段一向阶段二过渡的关键时期。它那套为系统编程量身打造的、极致安全的内存管理哲学，在 Web 开发、数据科学、GUI 应用等场景下，确实给很多开发者带来了巨大的心智负担。

Rust 社区内部，关于是否应该为了“易用性”而牺牲部分“极致性”的争论，也从未停止。比如，关于异步运行时的分裂（Tokio vs async-std）、关于标准库的精简与扩充，都反映了这种“青春期的烦恼”。

Rust 没有停滞，它只是在“成长的十字路口”，在思考自己到底想成为谁。

我们真正应该关注什么？

作为身处一线的工程师，我们应该如何看待 TIOBE 的这份“诊断书”？

第一，永远不要把“流行度”作为技术选型的唯一标准。

JavaScript 很流行，但你不会用它去写操作系统内核。COBOL 极其冷门，但全球的银行系统依然跑在它上面，顶级 COBOL 程序员的薪资高得吓人。

技术的价值，永远取决于它在特定场景下，解决了多大规模、多高难度的商业问题。

第二，警惕“易用性”的陷阱。

Go、Python 很简单。但这种简单，可能是以牺牲“运行时安全保证”（比如Python 的动态类型、Go的Nil指针等）为代价的。

Rust 的“难”，恰恰是把所有可能在深夜引发线上雪崩的风险，全部前置到了编译阶段。它用“编译时的痛苦”，换取了“运行时的安宁”。

这种设计哲学，对于金融交易、底层基础设施、航空航天等“不容有失”的领域来说，是无价之宝。

第三，对自己的成长负责，而不是对榜单负责。

与其每个月焦虑地刷新 TIOBE 的排名，不如去问自己几个更本质的问题：

• 我所处的行业，未来 3-5 年最核心的技术瓶颈是什么？
• 为了解决这些瓶颈，我需要掌握哪些不可替代的底层能力？
• 哪门语言的生态和哲学，与这个方向最契合？

你的技术护城河，从来不是由 TIOBE 的排名决定的，而是由你所处行业以及要解决问题的深度决定的。

小结：你的价值，与榜单无关

TIOBE 的这份榜单，与其说是一份严肃的技术报告，不如说是一场成功的“引流狂欢”。

它用一个看似客观的数据，精准地挑动了每个程序员心中最敏感的那根“身份焦虑”神经。

但作为身处一线的工程师，我们必须保持清醒。

衡量一门技术价值的唯一标准，从来不是它在搜索引擎上的热度，而是它在真实的商业世界里，解决了多大、多复杂、多有价值的问题。

当你在用 Rust 构建着下一代安全操作系统，或者用它重写着公司最核心的交易引擎时，你根本无需关心 TIOBE 上的排名是 16 还是 60。

因为你正在创造的价值，早已不是这些过时的“声量指标”所能衡量的。

你的技术栈没有背叛你，但你的认知，可能会。

今日互动探讨：

你觉得 TIOBE 对 Rust“增长放缓”的判断准确吗？你认为 Rust 陡峭的学习曲线，是它最大的优势，还是最大的障碍？

欢迎在评论区分享你的看法！

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

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

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

原「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 精进营」能成为你学习、进步、交流的港湾。让我们在此相聚，享受技术精进的快乐！欢迎你的加入！

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

© 2026, bigwhite. 版权所有.