本文永久链接 – https://tonybai.com/2026/02/06/go-2-dont-become-a-frankenstein-monster

大家好，我是Tony Bai。

“Go 2, please don’t make it happen.”

近日，一张充满讽刺意味的老梗图在 r/golang 社区又炸开了锅。图片的上方，是我们熟悉的 Gopher 吉祥物——那只呆萌、简单、甚至有点傻气的蓝色地鼠，它象征着 Go 语言纯粹而克制的灵魂。

而在图片的下方，这只 Gopher 发生了一场令人毛骨悚然的“变异”：它长出了巨大的龙翼，上面写着“Generics”（泛型）；它生出了锋利的机械利爪，标签是“Try/Catch”；它的身体变得臃肿不堪，缝合了“Mixins”（混入）、“Lambda 表达式”、“操作符重载”、“多态方法”等各种来自其他语言的特性。

这只被缝合得面目全非的怪兽，被标注为——“Go 2”。

时隔多年，这幅图再次引爆了社区，获得了数百个点赞和近百条激烈的评论。尽管 Go 语言的掌舵人 Russ Cox 在2023年的一篇名为“Backward Compatibility, Go 1.21, and Go 2”的博客文章中就早已明确表示“Go 永远不会有破坏性的 Go 2”，但这个话题依然像一根敏感的神经，触动了无数 Gopher 内心深处最隐秘的恐惧：我们热爱的这门语言，会不会最终也难逃“熵增”的宿命，变成另一个臃肿复杂的 C++ 或 Java？

今天，就让我们借着这场社区激辩，再次探讨一下 Go 语言的过去、现在与未来。如果 Go 真的变成了那个“缝合怪”，你还会爱它吗？

恐惧的根源：当“简单”成为一种罪过

帖子下的最高赞评论，道出了许多资深 Gopher 的心声：“想要 Go 2 的人，能不能去玩别的语言？”

这句话听起来充满火药味，但它背后隐藏着 Go 语言最核心的价值观冲突。在编程语言的鄙视链中，Go 常常因为“特性贫乏”而遭到嘲笑。

• “为什么没有三元运算符？写 if-else 手都酸了。”
• “为什么没有 map、filter、reduce？手写 for 循环太原始了。”
• “为什么没有异常处理？满屏的 if err != nil 简直是精神污染。”

对于习惯了 Python 列表推导式、Java 注解魔法或 Rust 模式匹配的开发者来说，初见 Go 语言简直就像是从现代文明回到了石器时代。这种“匮乏感”是真实的，也是痛苦的。

然而，对于另一群人来说，这种“匮乏”恰恰是 Go 最大的特性。

有位Go拥趸在评论中就犀利地指出：“Go 的表现力不来自于模仿 Turbo Pascal 或其他语言的语法糖，而来自于开发者对自己构建内容的清晰愿景。”

试想一下，如果 Go 真的引入了所有这些特性，它会变成什么样？

// 一个想象中的“变异版” Go 代码
try {
    var result = list.filter(x => x > 0).map(x => x * 2).reduce((a, b) => a + b);
    result ? process(result) : throw new Error("Empty result");
} catch (e) {
    logger.error(e);
}

这段代码看起来很“现代”，很“简洁”，对吧？但它还是 Go 吗？当你看到这段代码时，你能一眼看出它的性能开销吗？你能确定 filter 和 map 中是否有隐藏的闭包分配？你能确定 throw 会跳过哪些资源释放逻辑吗？

不能。 Go 的核心哲学之一是“所见即所得” (What you see is what you get)。Go 代码可能写起来啰嗦，但读起来极其清晰。没有隐藏的控制流，没有魔法般的隐式转换。如果为了迎合所有人的口味，把 Rust 的枚举、Java 的注解、Python 的语法糖都塞进 Go 里，那么 Go 就不再是 Go，而变成了一个拙劣的模仿者。

正如另外一位开发者所言：“如果我想要繁琐和过度设计，我为什么不去用 Java 呢？”

渴望的呼声：那些“不得不爱”的语法糖

然而，硬币的另一面是，社区的呼声并非全无道理。大家虽然嘴上说着“不要 Go 2”，身体却很诚实地想要一些具体的改进。在激烈的辩论中，有几个特性的呼声高居不下，它们代表了 Go 语言目前最真实的痛点。

真正的枚举 —— 呼声最高的“刚需”

这是目前 Go 社区最大的痛点之一。Go 现在的枚举实现方式是 const 加上 iota：

const (
    StatePending = iota
    StateRunning
    StateFailed
)

这本质上只是给整数起了一个别名。它最大的问题是缺乏类型安全。你完全可以把一个 State 类型的变量赋值为 100，编译器不会有任何怨言。而且，你无法像 Rust 或 Swift 那样，在枚举中携带额外的数据（Sum Types / Tagged Unions）。

一位开发者的评论获得了大量赞同：“我只想要真正的枚举。现在的枚举感觉像是黑客拼凑出来的。”

想象一下，如果 Go 有了类似 Rust 的枚举，我们的错误处理和状态机代码将会变得多么优雅和安全。这不仅仅是语法糖，这是对类型系统的一次重要补全。

空值安全 —— 生产环境的“救命稻草”

虽然 Go 有了泛型，但 nil 指针解引用依然是生产环境中的一大杀手。在 Java 和 C# 都在引入 Optional 或可空类型的大趋势下，Go 的 nil 处理显得有些落伍。

有人希望能引入 ?? (空值合并) 或 ?. (可选链) 运算符。

• 一位开发者提及：“只要给我空值合并和可选链，我就满足了。”
• 但反对的声音同样强烈。另外一位开发者惊恐地喊道：“别！我刚从 JS 的陷阱里逃出来，不想再跳进另一个。”

这种分歧展示了 Go 设计的艰难：每一个看似微小的语法糖，都可能引入新的复杂性和不可预知的副作用。

错误处理的简化 —— if err != nil 的审美疲劳

尽管 if err != nil 是 Go 的标志，但在业务代码中，它确实占据了大量的视觉空间，有时甚至掩盖了核心逻辑。

社区中一直有关于 try() 提案或 ? 操作符的讨论。大家希望能在保留“显式错误处理”这一核心语义的前提下，减少一些键盘敲击次数。但至今为止，并没有一个提案能完美地平衡“简洁”与“清晰”。甚至Go官方都不得不宣布，先将错误处理的语法糖改进放一放，缓一缓。

历史的镜鉴：Java 的教训与 C++ 的警示

为了理解为什么 Go 社区对“增加特性”如此警惕，我们需要把目光投向历史。

在评论区中，Java 成为了被反复提及的反面教材。许多从 Java 转过来的 Gopher 对 Java 的“过度设计”深恶痛绝。

• 注解地狱：Spring 框架中的注解虽然方便，但它让代码的运行时行为变得极其难以预测。你看着代码，却不知道它到底在干什么。
• 层层抽象：为了所谓的“灵活性”，Java 社区习惯于构建一层又一层的抽象，导致调用栈深不见底。

有人评论道：“Java 并没有强迫你写得那么繁琐，是‘企业级 Java’的文化导致了这一切。” 但问题在于，语言的特性往往会塑造社区的文化。当你提供了复杂的抽象能力，开发者就会忍不住去用它。

Go 的创始人 Rob Pike 曾说过，Go 是为了解决 Google 的软件工程问题而设计的。在 Google，有数万名工程师在同一个代码库上工作，人员流动频繁。代码的可读性、一致性和可维护性，远比“写得爽”更重要。

Go 通过“限制”开发者的能力（比如不支持继承、不支持重载），强迫大家写出风格一致、简单直白的代码。这是一种“防御性”的语言设计，它牺牲了上限（极致的表达力），保住了下限（代码不会烂得太离谱）。

现实：Go 2 其实已经发生了

在讨论的喧嚣中，有一个冷静的声音提醒大家：其实，我们已经身处 Go 2 的时代了，只是它不叫 Go 2。

回顾过去几年，Go 并非一成不变，而是在经历着一场惊心动魄的、却又润物细无声的进化。

• 模块化 (Go Modules)：从 GOPATH 到 go.mod，Go 的依赖管理经历了一次彻底的重构，解决了困扰社区多年的“依赖地狱”问题。
• 泛型 (Generics) 的落地：这是 Go 诞生以来最大的语言变动。经过长达十年的争论、数个方案的推翻重来，Go 团队最终在 1.18 版本中，以一种极其克制、与现有语法高度兼容的方式引入了泛型。它没有破坏现有的代码，也没有引入过度的复杂性。这是一个奇迹。
• for循环变量语义修复、函数迭代器、结构化日志 (slog)、工具链升级、性能优化…

Go 正在遵循 Russ Cox 当初提出的“渐进式演进”路线图。它没有像 Python 2 到 Python 3 那样，通过一个破坏性的“Go 2.0”版本来割裂社区，造成长达十年的痛苦迁移；而是选择了向后兼容这条最为艰难的道路。

正如一位开发者所言：“我爱 Go 的一点是，我可以拿着 10 年前的项目代码，用最新的编译器直接编译通过。这是一个疯狂的成就。”

这种稳定性，是商业公司敢于将核心业务押注在 Go 上的根本原因。

小结：在此刻，爱上“不完美”

这场关于 Go 2 的辩论，本质上是两种价值观的碰撞：“特性的丰富” vs “工程的克制”。

我们必须承认，Go 不是完美的。它确实有一些恼人的地方，有一些需要体力和耐心的重复劳动。但正是这些“不完美”，构成了 Go 独特的性格。

Go 注定不会成为一个拥有所有炫酷特性的语言。它就像那辆你从父辈那里继承来的老本田车：

它可能没有最先进的自动驾驶功能，没有最豪华的内饰，也没有令人血脉偾张的加速推背感。

但是，它极其可靠、结构简单、易于维修，并且总能把你安全地送到目的地。

当你在深夜维护一个高并发的微服务时，当你面对一个由离职同事留下的陌生代码库时，你会感谢 Go 的“简单”。你会庆幸没有那些魔法般的隐式转换，没有那些层层叠叠的抽象，只有一行行清晰、直白、甚至有点笨拙的代码，告诉你程序到底在做什么。

所以，与其期待一个面目全非的“缝合怪” Go 2，不如在当下，享受这种“简单”带来的确定性与安宁。

Go 2，请不要发生。因为现在的 Go，已经足够好。

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

你的“底线”在哪里？

Go 语言的简洁与克制，让它成了我们心中的那辆“本田车”。但如果真的有一次机会，你最希望 Go 引入的一个“语法糖”是什么？又或者，哪个特性的引入会让你觉得它彻底变了，让你决定弃坑？

欢迎在评论区留下你的“真爱宣言”或“退坑预警”！让我们一起探讨 Go 的未来模样。

如果这篇文章说出了你作为 Gopher 的心声，别忘了点个【赞】和【在看】，转发给你的伙伴，看看他们的“底线”又在哪里！

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

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

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

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/17/go-rust-zig-simplicity-vs-control

大家好，我是Tony Bai。

在系统编程的世界里，开发者似乎总是面临着一个残酷的二选一：是选择极致的简单与生产力，还是选择绝对的控制与零成本抽象？

这种纠结在 Go 与 Rust 的长期对峙中体现得淋漓尽致。然而，近日一位拥有十年 Go 经验的资深开发者在Zig社区的分享，似乎为这场二元对立的战争撕开了一道口子。他从 Go 迁移到 Zig 的经历，既是一个技术选型的故事，也是一场关于“我们到底需要什么样的编程语言”的深度辩论。

Go 的困境：当“简单”成为一种束缚

对于许多 Gopher 来说，Go 的简单是其最大的武器，但也是最深的痛点。

这位楼主坦言，尽管他深爱 Go 的简单，但在编写某些复杂系统时，这种“过度简化”让他感觉语言本身存在缺陷。

• 表达力的缺失：Go 缺乏像 Rust 那样的 Enum (带数据的枚举)、Option 和 Result 类型。在处理复杂状态和错误流时，Go 的代码往往显得啰嗦且缺乏约束力。
• “差不多”的无奈：为了保持简单，Go 在很多地方做了折中（比如 GC，比如泛型的实现方式）。当你需要榨干硬件性能或追求极致的内存布局时，Go 显得力不从心。

Rust 的围城：控制的代价是复杂度

如果嫌 Go 太简单，Rust 似乎是理所当然的替代者。但对于很多习惯了 Go “写完即运行”体验的开发者来说，Rust 的门槛是一堵高墙。

楼主表示，他喜欢 Rust 的核心概念（Structs, Enums, Option），但 Rust 为了内存安全而引入的借用检查器、生命周期以及复杂的异步模型，让他感觉“像是面对另一个 C++”。

这是一场灵魂拷问：为了获得控制权，我们真的需要背负如此沉重的认知包袱吗？

Zig 的破局：在“简单”与“控制”之间走钢丝

Zig 的出现，似乎精准地击中了 Go 与 Rust 之间的那个真空地带。对于这位 Gopher 来说，Zig 让他感到了久违的“刚刚好”：

1. 显式的哲学（像 Go）：Zig 没有隐式内存分配，没有隐藏的控制流，也没有预处理器。这种“所见即所得”的代码风格，与 Go 的可读性哲学高度共鸣。
2. 现代的类型系统（像 Rust）：Zig 提供了 comptime（编译期执行）和丰富的类型系统，弥补了 Go 在表达力上的短板，却又没有引入 Rust 那样复杂的生命周期概念。
3. 对 C 的降维打击：Zig 不仅是一门语言，更是一个强大的 C/C++ 构建工具链。它允许你无缝地与 C 交互，逐步迁移遗留代码，这是 Go (CGO) 和 Rust 都难以做到的顺滑体验。

社区的冷思考：没有免费的午餐

当然，这场灵魂拷问没有标准答案。社区的讨论也极其理性地指出了选择 Zig 的代价：

• 生态的荒原：与 Go 庞大的“标准库+第三方库”相比，Zig 的生态仍处于拓荒期。你可能需要自己造很多轮子。
• 内存管理的回归：Zig 没有 GC，也没有 Rust 的所有权模型。这意味着你回到了手动管理内存的时代（尽管有 defer 和 arena 等工具辅助）。对于习惯了 GC 的 Gopher 来说，这是一个必须跨越的心理门槛。
• 稳定性的豪赌：Zig 尚未发布 1.0，语言特性仍在变动。选择 Zig，意味着你愿意陪它一起成长，也愿意承担变动的风险。

小结：你的灵魂属于哪里？

这场讨论最终指向了开发者内心的自我定位：

• 如果你追求高效交付、团队协作和工业级的稳定性，Go 依然是不可撼动的王者。
• 如果你追求数学般的严谨、绝对的安全和零成本抽象，且不介意陡峭的学习曲线，Rust 是你的圣杯。
• 而如果你渴望掌控底层、厌倦了复杂的抽象、却又想要现代化的开发体验，Zig 也许就是你一直在寻找的那个“刚刚好”。

简单还是控制？这不仅是语言的选择，更是你作为工程师，想要如何与机器对话的选择。

资料链接：https://www.reddit.com/r/Zig/comments/1q38e50/im_really_surprised_by_how_simple_it_is_to/

你的“灵魂选择”

在“简单”与“控制”的天平上，你的心偏向哪一边？如果让你现在开始一个新项目，你会毫不犹豫地选择 Go，还是想尝尝 Zig 的鲜，亦或是死磕 Rust？

欢迎在评论区投出你的一票，并分享你的理由！ 让我们看看谁才是开发者心中的“白月光”。

如果这篇文章引发了你的选型思考，别忘了点个【赞】和【在看】，并转发给那个还在纠结学什么语言的朋友！

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

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

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

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2026/01/10/go-dropped-from-7th-to-16th-in-one-year

大家好，我是Tony Bai。

新年伊始，TIOBE 发布了最新的编程语言排行榜。当我满怀期待地去寻找 Go 的身影时，差点以为自己眼花了：

Go 居然从去年的第 7 名，断崖式下跌到了第 16 名！ 占比跌幅高达 1.37%，在这个榜单上几乎是“崩盘”级别的表现。

这是什么概念？这意味着在 TIOBE 的统计里，Go 现在的流行度还不如 Delphi/Object Pascal（第 9 名）和 Visual Basic（第 7 名）。

这就很离谱了。任何一个在 2025 年还在写代码的人，都不会觉得 Go 的生态已经萎缩到这种地步。

是 Go真的凉了吗？还是 TIOBE 的算法“疯”了？

平行宇宙：稳如泰山的 Go

为了验证我的认知是否出现了偏差，我特意查阅了 2025 年其他的权威榜单：

• GitHub Octoverse：Go 依然稳居前 10，云原生领域的统治地位不可撼动。
• Stack Overflow 开发者调查：Go 在“最想学习的语言”和“薪资最高语言”中依然名列前茅。
• JetBrains 生态报告：Go 开发者的数量在持续稳步增长，并登顶“最受期待”榜首，没有任何衰退迹象。

全世界都觉得 Go 挺好，唯独 TIOBE 觉得 Go 要完。这种巨大的反差，逼得我不得不去扒一扒 TIOBE 的底裤——它的排名算法到底是怎么算的？

扒皮 TIOBE：一个过时的算法游戏

根据 TIOBE 官方公布的定义文档，它的算法极其简单粗暴，甚至可以说——在 2026 年显得有些可笑。

它的核心逻辑只有一个公式：

在 25 个主流搜索引擎中，搜索 +” programming”，统计返回的页面数量。

就是这么简单。没有什么复杂的加权，没有什么开发者活跃度分析，就是数一数搜索引擎告诉你“有多少个网页提到了这个语言”。

这种算法在 20 年前或许有效，但在今天，它成为了导致 Go 排名暴跌的元凶。

元凶一：AI 杀死了“搜索结果页”

2025 年最大的变化是什么？是 AI Search。

当我们遇到编程问题时，越来越多的人不再去 Google 翻阅那几百万个搜索结果页面，而是直接问 ChatGPT、Claude 或者 DeepSeek。
TIOBE 明确表示：ChatGPT 等 AI 工具不被纳入统计，因为它们没有“返回结果数量”的计数器。

这就导致了一个悖论：越是热门、现代的语言（如 Go、Python(得益于AI模型训练与应用开发)），其用户群体越年轻、越拥抱新技术，也就越倾向于用 AI 解决问题。 这直接导致了这些语言在传统搜索引擎中的“查询热度”和“新内容生成量”出现显著下降。

相比之下，那些老旧的语言（如 VB、Delphi），其用户群体相对固化，且维护遗留系统时更多依赖传统的文档和论坛搜索，因此受到的冲击较小，甚至在对比中显得“逆势上扬”。

注：Python的占比相对于2025.01也下降了0.68%。

元凶二：Go 的名字太“吃亏”了

TIOBE 的核心搜索查询是 +” programming”。

这对于 Python、Java 这种专有名词来说问题不大。但对于 Go 来说，这就是个灾难。

• 通用词的悲剧：Go 是一个极其通用的英语单词。为了过滤掉“去（go）”的含义，TIOBE 必须强制加上 “programming” 后缀。
• 搜索习惯的改变：但在 2025 年，开发者还会搜 “Go programming” 吗？不会了。大家搜的是 “Go generics”、”Golang k8s”、”Goroutine leak”。
• 不成比例的过滤：随着搜索引擎算法日益智能，它开始更精准地理解用户意图，不再机械地匹配 “Go programming” 这个短语。这导致大量讨论 Go 技术的高质量页面（但没有显式包含该短语）被 TIOBE 的简单算法无情过滤。而像 “Python programming” 这种组合，因为 Python 本身的高辨识度，受到的影响要小得多。

元凶三：搜索引擎的“去水化”

Google 等搜索引擎在 2025 年大幅调整了算法，致力于打击 SEO 内容农场和低质量生成的页面。

Go 作为一个在云原生时代极速窜红的语言，过去几年充斥着大量的入门教程、培训班广告和搬运文章。搜索引擎的这一波“清洗”，可能不成比例地删除了大量包含 “Go programming” 关键词的低质、重复页面。

虽然页面总量少了，但生态的“干货密度”其实更高了。 然而，在 TIOBE 这种只看“数量”不看“质量”的算法眼里，这就被简单粗暴地解读为“热度暴跌”。而那些生态早已固化、鲜有新内容产生的老语言，反而躲过了这一劫。

注：以上也是笔者的主观分析，不一定与事实相符！

小结：看个乐呵就行

把 Go 排在 Visual Basic 后面，这本身就是一个笑话。

TIOBE 的这次排名暴跌，反映的不是 Go 语言的衰落，而是 TIOBE 这种基于“网页搜索量”的统计方法，在 AI 和现代互联网面前的全面崩塌。

它就像一个依然在用“收音机收听率”来衡量流行音乐热度的老人，已经无法捕捉流媒体时代的脉搏。

所以，各位 Gopher，该写代码写代码，该摸鱼摸鱼。Go 好着呢，别被这个离谱的排名吓到了。

你的“体感”排名

TIOBE 的数据确实让人啼笑皆非。在你心目中，Go 语言现在的真实热度应该排第几？你觉得还有哪个榜单能更客观地反映编程语言的现状？

欢迎在评论区晒出你的“心选榜单”，或者尽情吐槽这个离谱的排名！

如果这篇文章解开了你心中的疑惑，别忘了点个【赞】和【在看】，并转发给那些正在唱衰 Go 的朋友，打脸要快！

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

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

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

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

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

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

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

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

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

© 2026, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/12/15/go-language-anti-patterns-10-donts

大家好，我是Tony Bai。

“有哪些‘不要做’的教训，是你花了好几年才学会的？”

近日，在 r/golang 社区，这个简单的问题，引爆了一场关于 Go 语言“反模式”与“最佳实践”的集体反思。帖子下数百条评论，汇集了无数 Gopher 在真实项目中用“血与泪”换来的宝贵经验。这些教训，往往不是关于某个高深的算法，而是关于那些看似“理所当然”，却在不经意间为代码埋下地雷的日常习惯。

这篇文章，正是对这场集体智慧的一次系统性梳理。我们从中提炼出 10 条最核心的“不要做”法则，它们如同一份“避坑指南”，能帮助你绕开那些最常见的陷阱，更快地从一名“会写 Go 的程序员”，成长为一名“懂 Go 的工程师”。

不要过度封装包

Don’t overpackage things

初学者往往有一种冲动，想把代码组织成“语义化”的、层层嵌套的包结构。internal/models, internal/services, internal/repositories…… 这种源自其他语言（如 Java）的模式，在 Go 的世界里，往往是一种过早的、不必要的复杂性。

社区忠告：从一个 main.go 文件开始。努力思考，是否真的有必要将代码拆分到多个文件/包中。Go 的包，其主要目的是封装和依赖管理，而不是单纯的文件夹分类。在小型或中型项目中，一个清晰的、扁平的包结构，远比一个复杂的“企业级”目录树更易于维护。

不要滥用 channel 和 goroutine

Don’t just add in channels

并发是 Go 的“名片”，这使得许多开发者（尤其是新手）有一种“锤子心态”——看到任何问题，都想用 goroutine 和 channel 来解决。然而，不必要的并发，是复杂性和 bug 的温床。

社区忠告：

• 先问“是否需要”：你真的需要并发吗？如果不需要在线程间传递消息，你可能根本不需要 channel。一个简单的 sync.WaitGroup 或 sync.Mutex，在很多场景下都比 channel 更简单、更直接。
• 并发不是免费的：Go 让创建 goroutine 变得异常简单，但这并不意味着它是零成本的。过多的 goroutine 会增加调度器的负担，而 channel 的滥用则会使数据流变得难以追踪和调试。

不要盲目追求 DRY

Don’t be zealous about DRY

DRY 是编程的基本原则，但在 Go 的哲学中，它有一个更重要的“上级”——清晰性。为了消除几行重复代码，而引入一个复杂的接口或一个晦涩的辅助函数，往往得不偿失。

社区忠告：“一点点复制，胜过一点点依赖 (a little copy-paste is better than a little dependency)。” 当你发现自己在为了 DRY 而绞尽脑汁时，请停下来问问自己：这份重复，是否真的带来了维护上的痛苦？如果不是，那么接受它，可能是一个更明智的选择。

不要在同一个 PR 中既重构又添加新功能

Don’t refactor and add features in the same PR

在添加一个新功能时，顺手“优化”一下周围的代码，这看起来很高效。但实际上，这会让 Code Review 变得异常痛苦。Reviewer 无法清晰地分辨，哪些改动是为新功能服务的，哪些是纯粹的重构。这不仅增加了审查的难度，也提高了引入新 Bug 的风险。

社区忠告：遵循“童子军军规”——“让营地比你来时更干净”——是好的。但请将它分解为两个独立的、目标明确的 PR：一个只做重构，另一个（基于重构后的代码）只添加新功能。

不要跳过写测试，“就这一次”

Don’t skip writing tests “just this once”

这是所有开发者都曾屈服过的诱惑。“这个改动太小了”、“我百分之百确定它是对的”、“项目赶时间”…… 每一次“就这一次”的妥协，都在为未来的“技术雪崩”添砖加瓦。

社区忠告：将测试视为代码不可分割的一部分。在 Go 中，编写测试是如此简单和自然，以至于没有任何借口可以跳过它。你今天节省下来的 10 分钟，可能会在未来，让你或你的同事，花费数天时间去调试一个本可避免的生产问题。

不要害怕使用 sync.Cond

channel 非常强大，但它并非解决所有并发同步问题的“银弹”。社区中有一种“反 sync”的情绪，认为所有同步都应该用 channel 来完成。

社区忠告：sync.Cond 是一个被低估了的、极其强大的并发原语。当你需要基于某个特定条件来唤醒一个或多个等待的 goroutine 时（例如，一个任务队列的消费者在队列为空时等待），sync.Cond 往往比用 channel 实现的复杂信令机制，要更简单、更高效。不要因为不熟悉，就回避它。

不要返回接口

Returning interfaces. Don’t do it.

在函数签名中返回一个接口，看似遵循了“依赖倒置”的高级原则，甚至觉得这样更“灵活”。但实际上，这往往是一种过早的、有害的抽象。它剥夺了用户访问底层具体类型特有功能的能力，并且如果未来需要添加新方法，接口的变更会极其痛苦。

社区忠告：遵循 Go 的经典谚语：“接收接口，返回结构体 (Accept interfaces, return structs)。”

• 接收接口：让你的函数接收一个只包含其所需最小方法集的接口作为参数。这使得你的函数更容易被测试和复用（你可以传入任何满足该接口的实现，包括 Mock 对象）。
• 返回结构体：让你的函数返回一个具体的类型（通常是指针）。这给了调用者最大的灵活性。

经典范例：

看看标准库中的 os.Open，它返回的是 *os.File（具体结构体），而不是 io.Reader（接口）。
* 为什么这样做？ 因为 *os.File 不仅能读（Read），还能关闭（Close）、获取状态（Stat）、甚至改变权限（Chmod）。
* 灵活性：如果它返回的是接口，用户就无法使用 Chmod 等特有功能了。而返回结构体，用户既可以使用其全部功能，也可以在需要时，轻松地将其赋值给 io.Reader 接口来使用。这就是“返回结构体”带来的自由。

(注：只有当返回的类型是包内私有的、不希望外部直接访问的实现细节时，返回接口才是有意义的，例如 context.WithCancel 返回的是 Context 接口。)

不要过度依赖依赖

Don’t add dependencies without vetting

为了解决一个小问题，而引入一个庞大的、闪亮的第三方库。这在 Node.js 生态中很常见，但在 Go 社区，这通常被视为一种“危险信号”。

社区忠告：

• 先求诸标准库：在引入任何依赖之前，先问问自己：这个问题，标准库真的解决不了吗？
• 审慎评估：如果必须引入依赖，请仔细评估它：它的依赖树有多深？社区是否活跃？维护者是否可靠？一个简单的依赖，可能会为你整个项目，带来潜在的供应链安全风险和维护噩梦。

不要盲从

Don’t do [or not do] something simply because an authoritative voice recommended it

盲目地遵循某个“大神”、某篇“爆款”博客文章、或者某个“权威”推荐的模式，而没有结合自己的具体场景进行批判性思考。

社区忠告：上下文决定一切。YAGNI (You Aren’t Gonna Need It) 是一个好原则，但有时你确实需要提前设计。微服务很好，但有时单体就是最佳选择。没有银弹。最好的实践，是那些在你的团队、你的项目中，被证明行之有效的实践。

不要忘记，代码是给人读的

忘记了代码的最终读者是人类，而不是编译器。编写只有自己能看懂的“聪明”代码，或者忽略文档和注释的重要性。

社区忠告：

• 编写能让你的未来“自已”不会痛骂你的代码。
• 好的设计不是增加，而是保持本质的简单。代码即是负债 (Code is liability)。
• 不要忽视清晰文档的重要性。

小结：在“坑”里成长

这份清单，远非全部。社区的讨论中还充满了诸如“不要用 singleton 来做 mock”、“不要滥用 init 函数”、“不要在疲劳时 Review 代码”等无数宝贵的经验。

它们共同指向了一个核心思想：成为一名优秀的 Go 工程师，其过程不仅仅是学习语言的特性，更是一个不断反思、不断“踩坑”、并从“坑”中总结出属于自己“不要做”清单的修炼过程。希望这份来自社区的集体智慧，能让你在这条路上，走得更稳、也更远。

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

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

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

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

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

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

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

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

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

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

© 2025, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/12/10/russ-cox-interview-go-birth-evolution-future

大家好，我是Tony Bai。

他是 Go 语言的第二代掌门人，在长达十余年的时间里，引领着 Go 从一个内部实验项目，成长为云原生时代的霸主。他也是 Plan 9 的资深黑客，贝尔实验室精神的传承者。如今，他已将 Go 的帅印交给了下一代，转身投入到 AI 模型编码能力的研究中。

他就是 Russ Cox。

在 ACM ByteCast 的一场罕见的深度访谈中，Russ Cox 系统性地回顾了他从贝尔实验室的青葱岁月，到创立 Go 语言的初心，再到对 AI 时代编程语言未来的深刻思考。这既是一段个人回忆录，也是一部关于“如何构建持久的技术”的生动史诗，充满了值得每一位 Gopher 细细品味的智慧。

Go 的“前传”——源自贝尔实验室的“简单”基因

Go 语言对“简单”的极致追求，并非凭空而来，它的种子早已在贝尔实验室和 Plan 9 操作系统的沃土中埋下。

Russ Cox 的编程之旅，始于上世纪 90 年代末的贝尔实验室。作为一个高中生，他有幸在那个创造了 Unix 的传奇之地“厮混”，与 Brian Kernighan, Rob Pike, Ken Thompson, Dennis Ritchie 这些“上古巨神”一同午餐、交流。

“贝尔实验室和 Plan 9 给我最深刻的印记，就是对构建真正简单的事物的执着。那里的人们，那是一个小团队，他们在做着雄心勃勃的事情，而完成它们的最好方式，就是从简单的事情开始，构建那些真正坚固可靠的简单事物。”

这段经历，为他注入了“简单”的 DNA。然而，当他进入 MIT 读研时，他第一次遭遇了“现代 C++”的“恐怖与复杂”。他被当时的业界现状所震惊：多线程不可靠、异步回调横行…… 这让他深信：“一定有更好的方式。”

Go 的“创世纪”——“让我们做点让自己开心的事”

2008 年春天，当 Russ Cox 结束学业，准备进入工业界时，已经先行加入 Google 的 Rob Pike, Robert Griesemer 和 Ken Thompson 向他发出了邀请，他们正准备全职启动一个新语言项目。

这个项目的初心，极其纯粹和个人化。

“我们都曾在 Google 写过大量的 C++ 程序……我们只是再也不想写那种代码了。我们受够了。我们知道有更好的方式，并且我们确信能把它带给 Google 的工程师们。”

“我们想解决的问题是，我们想构建一个能让我们在 Google 开心地编写程序的系统。”

Go 语言的诞生，并非一次自上而下的战略规划，而是一场由几位顶尖工程师发起的、旨在解决自身痛苦的“自救运动”。他们见识过更好的开发环境（Plan 9, Modula-3, Smalltalk），他们无法忍受现代 C++ 的复杂性。Russ Cox 甚至坦言：“说实话，我当时愿意付钱换取和他们一起工作的机会，而 Google 反而付钱给我。这对我来说是双赢。”

Go 的“演进哲学”——稳定压倒一切

从 Plan 9 的“无人问津”，到 Go 的巨大成功，Russ Cox 对开源社区的建设和语言的演进，有着极其深刻的理解。他认为，Go 的成功，很大程度上源于其对“稳定”的执着。

“进步可以有多种形式，一种是不稳定的进步，一种是稳定的进步。我们竭尽全力去寻找稳定的形式，而这通常意味着做得比人们要求的更少，但同时又能让他们解决自己的问题。”

他举了 go test 与 JUnit XML 格式集成的例子。社区曾强烈要求 go test 直接输出 JUnit 格式的 XML。但 Go 团队拒绝了，因为他们不想成为一个复杂 XML 格式的“专家”和“维护者”。

Go 团队的解决方案是：

1. 定义一个极其简单的、稳定的、机器可读的 JSON 输出格式。Go 团队只承诺维护这个简单格式的稳定性。
2. 告诉社区：“然后，你们可以自己写一个从这个 JSON 到你们所需 XML 的转换器。现在，你们可以自己解决自己的问题，而无需等待我们来解决。”

这种“授人以渔”而非“授人以鱼”的哲学，通过提供稳定、正交的底层构建块(build block)，赋能社区在其上构建自己的“进步”，这正是 Go 生态能够健康、蓬勃发展的核心秘诀。

AI 时代的“灵魂拷问”——我们还需要 Go 吗？

如今，Russ Cox 的工作重心已转向“理解和提升 AI 模型的编码能力”。对于 AI 是否会取代程序员这个终极问题，他给出了一个充满历史纵深感的、冷静的回答。

AI 只是进化的又一级台阶

他认为，AI 与编程语言的关系，是计算机发展史上“抽象层次不断提升”这一宏大叙事的延续。

• 40年代：我们通过手动连接电线来编程。后来，我们发明了解释器，用“数据”代替了“电线”。
• 50年代：我们有了 FORTRAN，用 ax² + bx + c 这样的公式，代替了手写机器指令。
• 今天：AI 正在将一些我们曾认为“只有人能做”的工作自动化，比如编写样板代码、调试简单问题。

“我认为 AI 将融入同样的模式……我们会将一些关注点交接出去，然后我们会找到更新、更大的事情来专注。每当我们的能力增长，或者我们将一些工作卸载给机器时，我们的雄心也会随之增长。”

AI 不会让我们失业，它只会让我们站到更高的起点，去挑战更宏大的问题。

编程语言不会消亡，清晰性永恒

Russ Cox 坚信，无论 AI 如何发展，人类可读、行为确定的编程语言都不会消亡。

“英语不会成为编程语言，因为它的歧义性太高了……最终，我们描述的依然是一门编程语言。”

“拥有一门人类可以阅读、理解的编程语言，这一点仍然至关重要。这样，当计算机行为不端时，你可以看着代码说：‘哦，我明白了为什么在这些指令下，它没有做正确的事。’”

AI 可能会帮助我们编写代码，但代码本身，作为人与机器之间那个最基础、最可靠的契约，其地位无可替代。

Go 在 AI 时代的定位

Go 诞生的初衷，是为了解决 20 年前兴起的“多核网络系统”这一巨大挑战。Russ Cox 认为，AI 很有可能在未来提出另一个同等级别的挑战，催生一门全新的语言。

“也许会有一门专为训练模型而生的新语言。Python 目前表现出色，但很容易相信你可以用一门定制语言做得更好。但整个世界并不会都在训练模型。”

他认为，世界上有大约 300 万 Go 开发者，但需要编写模型训练代码的人远少于此。这意味着，Go 作为一门为构建大规模、高并发网络服务而生的语言，其核心价值主张在 AI 时代不仅没有过时，反而愈发重要——因为所有的 AI 模型，最终都需要通过稳定、高效的服务来提供价值。

给后辈的忠告——如何构建持久的事业？

在访谈中，Russ Cox 还给所有有志于创造持久价值的年轻工程师，分享了两条极其宝贵的建议：

1. 花时间去真正理解问题：“很多时候，人们很容易满足于第一个能工作的方案。而我做过的大部分有价值的事，都来自于回头审视一个问题，然后感觉：‘实际上，我还没有完全理解它，我应该再试一次。’” 深入挖掘，直到你发现一个更简单、更根本的解决方案。

2. 找到让你兴奋的环境：“如果你对一件事感到兴奋，你早上醒来就想继续做它，那么你最终能完成的工作，将远超那些只为完成 8 小时任务的人……去找到那些能真正激励你的事情。”

领导力的传承 —— “最重要的期末考试，是退到一旁”

在访谈的最后，Russ Cox 分享了他对领导力，特别是开源项目领导力传承的深刻见解。这或许是整场对话中最具智慧和温度的部分。

他认为，开源社区的领导力，本质上是一种“社会性事业” (social endeavor)，沟通、协作、建立共识的能力，远比纯粹的编程能力更重要。而一个领导者最终极的考验，并非是他能做出多少贡献，而在于他能否以及何时选择“退到一旁”。

“最终，对领导者来说最重要的期末考试，就是退到一旁，然后说：‘好吧，我甚至不需要再在这里了。现在你可以领导这个了。’ 而这很难。”

Russ Cox 坦言，做自己擅长的事情是舒适和安全的，但他清醒地认识到，“项目需要新的想法和新的视角”。他回顾了 Go 领导权的两次交接：

1. 从 Rob Pike 到 Russ Cox：一次非正式的、渐进的交接。Rob Pike 邀请他加入，并在某个时刻悄然地“把项目交给了我，我突然就负责了”。
2. 从 Russ Cox 到 Austin Clements：一次更正式的交接。在领导 Go 长达十年之后，Russ Cox 在 2023 年正式将帅印交给了 Austin Clements。

他强调，这种传承的意义在于：

“确保项目能超越某个特定的人而存在，并且也能获得它们所需要的新视角和新想法。”

这不仅仅是一次权力的交接，更是一位卓越领导者对项目未来的深谋远虑和无私奉献。它确保了 Go 这艘大船，能够在新船长的引领下，继续朝着更广阔的海域航行。

结语

从贝尔实验室的“简单”初心，到 Go 语言的“稳定”哲学，再到对 AI 时代的冷静远见，Russ Cox 的这场访谈，为我们描绘了一位顶尖工程师和技术领袖的心路历程。

他的故事告诉我们，构建持久的技术，其秘诀不在于追逐一时的潮流，而在于深刻地理解问题，坚守核心的原则，并始终保持对创造的热情。这或许也是 Go 语言之所以能穿越喧嚣，成为今天这个样子的根本原因。

资料链接：https://learning.acm.org/bytecast/ep78-russ-cox

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

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

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

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

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

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

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

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

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

© 2025, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/12/06/zootopia-distributed-system-written-in-go

大家好，我是Tony Bai。

文章开始前，先给各位道个歉，今天的标题确实有点“党”。

毕竟，非要说一个满是毛茸茸动物的动画片是用 Go 语言写的，这脑洞开得确实有点大。

但请原谅一个老程序员的“职业病”。

为了迎接本周末《疯狂动物城2》的观影家庭活动，上个周末，我特意腾出时间，陪家里5岁的二娃重温了第一部经典。原本我是想好好享受亲子时光的，可看着看着，作为写了十几年代码的程序员，我的关注点却莫名其妙地“跑偏”了。

当看到那座容纳了冰川、沙漠、雨林，拥有千万级“居民并发量”的超级城市运转得如此丝滑时，我脑子里的画面变了：这越看越像一个设计精良的云原生分布式系统；而那个身手敏捷的兔子警官，怎么看都像一只跑在服务器里的 Gopher……

于是，我忍不住这股“胡思乱想”的冲动，决定一本正经地胡说八道一番。

如果你也好奇，当一个架构师戴着“代码滤镜”看电影时，到底看到了什么？不妨继续听我聊聊

在我眼里，如果要把这座“动物城”搬到服务器上，它的底层架构，一定是用 Go 语言写的。

为什么这么说？因为陪娃看电影的过程中，我仿佛看到了 Go 语言设计哲学的完美具象化。

那个巨大的“空调墙”与容器化

电影最震撼的一幕，莫过于朱迪坐火车进城。

火车穿过烈日炎炎的撒哈拉广场（Sahara Square），下一秒就钻进了冰天雪地的冰川镇（Tundratown）。

女儿指着屏幕好奇地问我：“爸爸，为什么那边那么热，这边这么冷，它们在一起不会化掉吗？”

我指着那道巨大的分隔墙说：“因为有那堵墙呀，它把热气和冷气隔开了。”

在那一刻，我脑子里闪过的其实是 Docker 和 Kubernetes。

在传统的系统里，不同环境的应用混在一起很容易“打架”（环境冲突）。而在动物城里，为了让北极熊（需要低温库）和骆驼（需要高温环境）在同一台“物理机”上共存，设计师构建了最极致的环境隔离。

这不正是 Go 语言统治的云原生世界吗？

Go 语言构建了 Docker，构建了 Kubernetes。正是这些基础设施，像那道巨大的空调墙一样，通过 Namespace（命名空间）和 Cgroup（资源限制），让成千上万个习性迥异的“服务”互不干扰，在此消彼长的流量洪峰中，不仅没“化掉”，还活得很好。

树懒“闪电”与高并发的噩梦

重温经典，依然被树懒“闪电”查车牌那段笑出内伤。

女儿笑得在沙发上捧腹：“爸爸，他太慢了！朱迪急死了！”

我跟着笑，但心里却是一阵恶寒——这简直是每一个后端工程师的噩梦：主线程阻塞（Blocking I/O）。

试想一下，如果动物城的市政大厅系统是单线程的，一只树懒卡在窗口办业务，后面排队的一万只动物全得等着。整个城市的吞吐量（QPS）瞬间归零，系统直接宕机。

但动物城（Zootopia）作为一个千万人口的超大系统，依然运转良好，说明它底层一定解决了这个问题。

如果是用 Go 写的，这就很好解释了。

Go 的设计哲学里，最核心的就是“高并发”。面对慢吞吞的“树懒式”任务（比如网络等待、文件读取），Go 不会傻等。它会派出一个轻量级的 goroutine（协程）去盯着树懒，主线程立马转头去处理下一只豹子或兔子的请求。

在这个庞大的系统里，也许有成千上万只“树懒”在慢动作，但整个城市依然像朱迪一样反应灵敏、健步如飞。这就是 Go 语言 GMP 调度模型的魔力。

朱迪警官：小身材，大能量

最后，说说我们的主角，兔子朱迪。

在满是大象、犀牛、北极熊的警局里，朱迪显得太小了。她没有庞大的身躯，起初也不被看好，被安排去贴罚单。

这像极了 Go 语言刚诞生时的处境。相比于 Java（大象）的厚重、C++（犀牛）的复杂，Go 显得语法简单、标准库精简，甚至生成的二进制文件都很小，一度被认为是“玩具语言”。

但朱迪凭什么破了大案？

靠的是灵活性、执行力和低资源消耗。

她能钻进犀牛进不去的狭窄管道（相对低内存的占用），她能在他人的视野盲区快速穿梭（极速启动）。

在构建现代微服务架构时，我们越来越不喜欢笨重的“单体应用”，而倾向于像朱迪这样小而美、独立部署、逻辑清晰的服务。

Go 语言就是代码世界里的“朱迪”。它剔除了所有花哨的语法糖，强制你写出清晰（甚至有点死板）的代码，但正是这种克制和高效，让它成为了支撑起整个动物城（云原生生态）最坚实的骨架。

写在最后

电影结束了，女儿意犹未尽，还在模仿朱迪的动作。

她问我：“爸爸，下周我们去看《疯狂动物城》第二部，朱迪会不会变得更厉害？”

我说：“肯定会啊，因为她一直在努力让这个城市变得更好。”

作为程序员，我们写下的每一行代码，何尝不是在构建一个虚拟的“动物城”？我们选择 Go，选择各种架构，不过是为了让这个系统更包容、更稳定，让里面的“居民”生活得更好。

这周末，我将带娃直击《疯狂动物城2》。 听说这一次，动物城面临了前所未有的复杂危机。

届时，我会继续为大家带来“程序员眼中的《疯狂动物城2》”，看看在新的挑战下，我们的“系统架构”又该如何进化？

敬请期待！

互动话题：

在重温经典电影时，你有没有因为“职业病”而产生过什么奇怪的联想？欢迎在评论区分享你的脑洞！

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

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

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

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

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

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

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

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

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

© 2025, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/11/30/ice-assertion-failed-with-append

大家好，我是Tony Bai。

在软件开发中，我们有时会遇到一些“显而易见”的错误。对于 Go 开发者而言，append 内建函数的第一个参数必须是切片，似乎就是这样一个“常识”。然而，当一个本应产生清晰编译错误的“常识性”错误，却导致了 Go 1.25.4 编译器的内部崩溃 (Internal Compiler Error, ICE) 时，事情就变得不再简单。

近期，Go 社区报告的一个 Bug (#76220) 和 Go 核心团队的后续跟进 (#76226)，为我们上演了一出精彩的“技术侦探剧”。这个故事不仅关乎一个 Bug 的修复，更深刻地揭示了 Go 语言规范的演进哲学：在语言的设计中，没有不言自明的“常识”，只有需要被精确定义的“规范”。

案发现场：一个“不该发生”的内部编译器错误 (ICE)

故事始于一位开发者 (@anderseknert) 在重构代码时，无意中写下了一段临时性的、显然无效的代码：

package main

func main() {
    s := "hello"
    // 错误：append 的第一个参数是 untyped nil，而非 slice
    msg := append(nil, s...)
    print(msg)
}

所有 Gopher 都知道这段代码不应该通过编译。事实上，在 Go 1.24 中，编译器会给出一个清晰、正确的错误提示：

first argument to append must be a slice; have untyped nil

然而，在 Go 1.25.4 中，同样的代码却导致了编译器自身的恐慌 (panic)，抛出了一个致命的内部编译器错误 (ICE)。这是一个严重的回归 (Regression)，因为它破坏了工具链的健壮性：

$go run main.go
# command-line-arguments
<unknown line number>: internal compiler error: panic: cmd/compile/internal/types2/builtins.go:1093: assertion failed

Please file a bug report including a short program that triggers the error.

https://go.dev/issue/new

从修复 Bug 到修正规范：Griesemer 的深层思考

Go 核心团队的 Robert Griesemer 迅速认领并修复了这个 Bug。然而，他并没有止步于此。在修复的过程中，他敏锐地洞察到了这个 Bug 能够产生的深层原因——Go 语言规范中一处极其微妙的文本歧义。

他为此创建了一个新的 issue (#76226)，专门探讨 append 特殊用法的规范描述问题。

规范中的“漏洞”

append 有一个广为人知的特殊用法：可以将一个 string 的内容追加到一个 []byte 切片后。Go 语言规范中对这个特殊情况的描述（旧版）是：

As a special case, append also accepts a first argument assignable to type []byte with a second argument of string type…
(作为一个特例，append 也接受一个可赋值给 []byte 类型的第一个参数，以及一个字符串类型的第二个参数…)

Griesemer 指出，问题就出在这里：在 Go 中，预声明的标识符 nil 是可以赋值给任何切片类型的，包括 []byte。

因此，如果一个开发者（或者未来的 AI 代码生成器）严格地、像解析法律条文一样去解读这段规范，他完全有可能得出一个“合乎逻辑”的结论：append(nil, “string”…) 应该是合法的！

这种规范文本与编译器实际行为之间的“缝隙”，正是滋生 Bug 和混乱的温床。

“滴水不漏”的修正案

为了彻底消除这种歧义，Griesemer 提交了一份对语言规范的修改提案。

旧版描述:

…accepts a first argument assignable to type []byte…

新版描述 (Go 1.26):

…accepts a slice whose type is assignable to type []byte…
(…接受一个其类型可赋值给 []byte 的切片…)

这个改动极其微小，但意义重大。它通过明确加入 “slice” (切片) 这个词，将隐含的“常识”变成了明确的“规则”，从根本上堵住了任何可能的误读。

对 Go 开发者的影响与启示

这个从 Bug 修复到规范修正的完整闭环，为我们揭示了 Go 社区和核心团队工作的几个重要侧面：

1. 严谨性高于一切：Go 团队追求的，不仅仅是让编译器“在大多数情况下做对的事”，而是让语言的规范、实现和用户直觉三者之间，达到尽可能的统一和精确。
2. 社区报告的价值：一个开发者在日常工作中遇到的工具链崩溃，只要被清晰地报告出来，就可能成为推动语言本身进步的催化剂。这体现了 Go 社区开放、协作的强大力量。
3. Go 是一部“活的法典”：Go 语言规范并非一成不变的石碑。它在社区的共同监督和核心团队的精心维护下，持续地、审慎地进行着自我完善，以追求更高的清晰度和健壮性。

小结：简单背后，是极致的严谨

append(nil, “string”…) 的故事，是 Go 语言演进哲学的一次完美缩影。它始于一个看似简单的编译器 Bug，最终却升华为对语言核心规范的一次“精炼提纯”。

这个过程告诉我们，Go 语言之所以能够在大规模工程中表现出强大的可靠性，不仅仅因为它拥有 goroutine 或 channel 等明星特性，更在于其背后，有一个对语言精确性抱有近乎“偏执”追求的团队和社区。

正是这种对每一个细节、每一个词语的反复推敲，才共同铸就了 Go 语言那“于细微处见真章”的工程之美。

资料链接：

• https://github.com/golang/go/issues/76226
• https://github.com/jamlee-t/go/commit/5241d114f55cfa69a4bf8f2051f5d83d1f618859

聊聊你遇到的“诡异”Bug

这个由append引发的故事，让我们看到了细节的重要性。你在日常开发中，是否也曾遇到过某个让你“怀疑人生”、最终发现是源于对语言规范理解偏差的Bug？或者，你对Go语言规范的严谨性有什么特别的体会？

欢迎在评论区分享你的“探案”经历！

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

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

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

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

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

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

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

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

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

© 2025, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/11/27/dingo-go-typescript-moment

大家好，我是Tony Bai。

Go 语言自诞生以来，以其极简主义哲学（Simplicity）赢得了全球开发者的青睐。然而，这种极简也伴随着长期的痛点：

• 满屏的 if err != nil。
• 缺失的和类型（Sum Types/Enums），导致状态表达含糊。
• nil 指针带来的运行时 panic 风险。
• 泛型虽已到来，但函数式编程体验（如 map/filter）依然匮乏。

在每年的 Go User Survey 中，这些问题总是名列前茅。

Gopher们渴望“越狱”，但Go 核心团队对此保持审慎，这不仅是为了保持语言的纯粹，也是为了向后兼容。

一个名为dingo 的开源项目的出现，试图打破这一僵局。它自称是 “逃逸的 Go”（Go that escaped）。就像 TypeScript 之于 JavaScript，dingo 试图在不改变 Go 运行时、不引入额外依赖的前提下，通过编译时转译，为 Gopher 们提供现代化的语法糖和类型安全。

在本文中，我们就来深入剖析 dingo 的核心机制与创新语法，看看它是如何在保持 Go 零运行时开销的同时，实现那些 Gopher 们梦寐以求的现代语言特性的。

dingo 是什么？

简单来说，dingo 是一门元语言（Meta-language）。它拥有类似 Rust 或 TypeScript 的现代语法，但最终会被编译成纯粹的、符合惯例的 Go 代码。

其核心价值主张包括：

1. 零运行时开销：编译产物就是标准的 Go 代码，性能与原生 Go 完全一致。
2. 向后兼容：可以直接引入现有的 Go 包，生成的代码也可以被其他 Go 项目引用。
3. 类型安全增强：引入 Option 和 Result 类型，语法层面消灭空指针异常。
4. 人体工程学升级：通过?操作符和模式匹配(Pattern matching)，大幅减少样板代码。

注：为什么叫 dingo（澳洲野犬）？dingo项目的README 中有一个有趣的隐喻：Go 的吉祥物 Gopher（地鼠）是规矩的、被管理的；而 dingo（澳洲野犬）曾是家犬，后来逃入荒野，恢复了野性。dingo 语言依然保留了 Go 的基因，但它拒绝被传统的规则束缚——它代表了未经许可的自由。

核心特性与代码对比

dingo 并非为了标新立异，而是为了解决实际问题。以下是它如何通过转译解决 Go 的四大痛点：

错误传播：告别 if err != nil

Go 的错误处理不仅啰嗦，而且容易打断阅读逻辑。dingo 引入了类似 Rust 的 ? 操作符。

dingo 写法：

// 看起来像 Rust，实际上是 Go 的超集
func processOrder(orderID: string) -> Result<Order, Error> {
    let order = fetchOrder(orderID)?          // 如果出错，直接返回 Err
    let validated = validateOrder(order)?     // 自动解包 Ok 的值
    let payment = processPayment(validated)?
    return Ok(payment)
}

转译后的 Go 代码（自动生成）：

func processOrder(orderID string) (Order, error) {
    order, err := fetchOrder(orderID)
    if err != nil {
        return Order{}, err
    }

    validated, err := validateOrder(order)
    if err != nil {
        return Order{}, err
    }
    // ...以此类推
}

我们从上面示例代码的字面上就能看到收益：样板代码减少约 67%，业务逻辑一目了然。

Sum类型与模式匹配

这是 Go 社区呼声最高的功能之一（[Proposal #19412](在本文中，我们就来深入剖析 Dingo 的核心机制与创新语法，看看它如何在保持 Go 零运行时开销的同时，实现那些 Gopher 们梦寐以求的现代语言特性。)）。dingo 通过 enum 和 match 完美实现了这一点。

dingo 写法：

enum Shape {
    Circle { radius: float64 },
    Rectangle { width: float64, height: float64 },
    Point,
}

func area(s: Shape) -> float64 {
    match s {
        Circle(r) => 3.14 * r * r,
        Rectangle(w, h) => w * h,
        Point => 0.0
    }
}

dingo 将 enum 转译为 Go 的 struct + tag（标签联合体），并生成辅助方法（如 IsCircle(), NewCircle()）。match 语句在编译时会进行穷尽性检查（Exhaustiveness Checking），如果你漏掉了一种情况，编译就会报错。

3. 空值安全

受 Swift 和 Kotlin 启发，dingo 引入了安全导航(Safe navigation)操作符 ?. 和空值合并操作符 ??。

dingo 写法：

// 还在写嵌套的 nil 检查吗？
let city = user?.address?.city?.name ?? "Unknown"

转译后的 Go 代码：

这会被展开为一系列的 if 检查或立即执行函数表达式，确保不会发生 panic。

4. 函数式编程工具

dingo 写法：

let numbers = []int{1, 2, 3, 4, 5}
let doubled = numbers.filter(|x| x % 2 == 0).map(|x| x * 2)

支持 TypeScript 风格的箭头函数 (=>) 或 Rust 风格的管道符 (||)。

技术架构与实现原理

dingo 的实现非常务实，它没有重写整个 Go 编译器，而是采用了两阶段转译架构：

编译器架构

• Stage 1: 预处理器 (Preprocessor)
  • 处理 dingo 特有的语法糖（如 ? 操作符、enum 定义、类型注解 : Type）。
  • 使用基于正则和文本的转换，将 dingo 代码转换为“合法的”但包含特殊标记的 Go 代码。
• Stage 2: AST 转换 (Plugin System)
  • 利用 Go 原生的 go/parser 解析代码。
  • 通过插件系统（Plugins）对 AST（抽象语法树）进行语义层面的转换。例如，将 Result 展开为具体的 struct 定义。
• Code Generation: 最后使用 go/printer 输出格式化好的 Go 代码。

IDE 支持的秘密武器：Source Maps

许多转译语言失败的原因是调试体验差——报错指向生成的代码，而不是源码。

dingo 实现了精确的 Source Maps (v1 格式)。

• 它建立 .dingo 文件和生成 .go 文件之间的双向映射。
• LSP 集成：dingo 开发了一个 LSP 代理（Proxy），它包装了官方的 gopls。当你请求“跳转定义”时，代理拦截请求，利用 Source Map 将位置从 dingo 坐标转换到 Go 坐标，发送给 gopls，拿到结果后再转换回来。这样，你在 VS Code 中写 dingo，享受的是 Go 级别的智能提示和重构能力。

混合包管理策略

dingo 采用了一种聪明的混合策略来解决生态兼容性：

• 应用开发：保留 .dingo 文件，忽略生成的 .go 文件。开发体验类似 TypeScript。
• 库开发：在发布时，将 .dingo 转译为 .go 并提交到版本控制系统。
• 意义：任何纯 Go 项目都可以 go get 一个用 dingo 写的库，而不需要安装 dingo。这是生态融合的关键。

哲学与争议：为什么这很重要？

dingo 的 项目说明文档中提出了一个深刻的观点：“自私地使用 dingo，顺便推动 Go 的演进。”

TypeScript 最初并非为了改变 JavaScript 标准，而是为了让开发者在大项目中活下来。但随着 TS 的普及（Async/Await, Optional Chaining），这些特性最终被吸纳进 ECMAScript 标准。

dingo的对 Go 核心团队的参考价值，和TS类似。

Go 核心团队在引入新特性时非常依赖“证据”而非“理论”。 Proposal #19412 尚未被accept，是因为缺乏 Go 语境下的具体实现范例。但 dingo 如果能拥有 5 万开发者，它就提供了一份实证数据：

• “使用了 ? 操作符的项目，代码量减少了 X%。”
• “和类型在 Go 的 runtime 上运行良好，并没有导致性能下降。”

因此，dingo 不是 Go 的竞争者，它是 Go 未来的沙盒。

上手指南与现状

目前，截至本文编写时， dingo 还处于 v0.3.0-alpha 阶段，主要核心特性（Sum类型、模式匹配、错误传播、LSP 支持）完成度还不高，仅适合向往拥有Rust、TypeScript等表达力更强的语法的Gopher尝鲜体验之用。

快速安装

# 克隆仓库并构建编译器
git clone https://github.com/MadAppGang/dingo.git 或 git clone --depth=1 git@github.com:MadAppGang/dingo.git
cd dingo && go build -o dingo ./cmd/dingo

# 将 dingo 加入环境变量 (可选)
export PATH=$PATH:$(pwd)

验证安装结果：

# dingo version

Hello World

# 编写 hello.dingo

package main
func main() {
    let msg = "Hello from dingo"
    println(msg)
}

# 编译并运行（dingo 会自动调用 Go 编译器）
dingo run hello.dingo

运行过程中，dingo会生成转义后的hello.go代码：

package main

func main() {
        msg := "Hello from dingo"
        println(msg)
}

大家通过转义后的代码，也可以看到它的转换过程和原理。

小结

dingo 是一个大胆的实验。它证明了我们可以在不分叉 Go 语言、不分裂生态系统的前提下，拥有现代化的语言特性。

不过，目前dingo的完成度还非常低，很多项目自带的example都build/run failed，这也是本篇文章可以运行的示例较少的原因:(。根据作者的Roadmap，目前很多新增的语法特性还处于未完成阶段。

但对于 Gopher 来说，如果你厌倦了 if err != nil，将来一旦完成度上来的dingo 很值得一试。即使你坚持使用纯 Go，dingo 的存在也是一件好事——它是一只被放入沙丁鱼群的鲶鱼，或许能激活 Go 语言演进的一池春水。

正如dingo项目宣言所说：这是你的语言，你的规则。无需委员会批准。

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

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

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

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

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

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

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

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

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

© 2025, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/11/24/google-adk-go-in-action

大家好，我是Tony Bai。

上周，我花了一个下午，仅仅是为了让一个Python写的Agent能稳定地调用我Go服务里的一个简单函数。在那一刻，看着屏幕上纠缠的gRPC、Python虚拟环境和混乱的日志，我脑海里只有一个念头：这不对劲，这绝对不是软件工程该有的样子！

显然，不仅仅是我一个人在为此焦虑。

就在最近，一个名为 google/adk-go 的项目悄然开源，并迅速霸榜 GitHub Go 语言趋势榜长达一周之久！ 全球的 Gopher 似乎都在用脚投票，表达着同一个渴望：我们受够了“炼丹”，我们要回归工程！

过去的一年，AI 的浪潮席卷了整个技术圈。我们 Gopher，作为构建云原生世界的中坚力量，看着 Python 社区在 AI 领域“杀”得热火朝天，心中或许都有一个共同的疑问：

“这场 AI 的盛宴，我们 Gopher 的主菜在哪儿？”

我们习惯了用 goroutine 优雅地处理并发，用 channel 安全地传递消息，用静态编译的单个二进制文件征服任何服务器。我们是天生的“工程师”，我们信奉的是可测试、可维护、可部署的软件工程哲学。

然而，当我们尝试踏入 AI Agent 的世界时，却常常感觉自己像一个闯入了“炼丹房”的“机械师”。面对那些需要反复“吟唱咒语”（调 Prompt）、结果飘忽不定的“丹炉”（模型），我们不禁会问：

• 我的 Agent 行为不稳定，怎么写单元测试？
• Prompt 稍微一改，整个“丹方”都可能失效，版本管理怎么做？
• 我如何将这个“充满魔法”的 Python 脚本，与我现有的 Go 微服务体系优雅地集成，而不是变成一坨无法维护的“耦合怪”？

这些问题，不是因为我们不懂 AI，而是因为我们太懂工程。我们厌倦了“炼丹”式的不确定性，我们渴望一种能将 AI 的强大能力，用严谨的工程纪律约束起来的解决方案。

现在，Google 亲自下场，为我们递来了“工程图纸”。

Google ADK for Go：写给工程师的 AI Agent 开发框架

这个霸榜的项目，全称是 Agent Development Kit (ADK) for Go。

这不是又一个“玩具”或“研究性”框架。从它的设计理念中，我看到了一个清晰而坚定的信号——AI Agent 开发，正在从“炼丹”式的“艺术创作”，全面进入“工程化”的“工业生产”时代。

而 ADK for Go 的核心哲学，与我们 Gopher 的信仰不谋而合，那就是——代码优先 (Code-First)。

• 你的 Agent，就是你的 Go 代码： 不再有晦涩的 YAML，不再有天书般的“链”，Agent 的所有逻辑、决策、工作流，都由你亲手编写的、地地道道的 Go 代码来定义。
• 天生的可测试性： 你的 Agent 就是一个实现了 agent.Agent 接口的 struct。这意味着什么？你可以像测试任何 Go 代码一样，go test 走起！Mock 依赖、断言行为，所有你熟悉的工程实践，全部回归。
• Git 即版本管理： Agent 的每一次进化，都是一次清晰的 git commit。Code Review、版本回滚，一切都尽在掌握。
• 云原生无缝集成： 它就是一个标准的 Go 模块，可以被无缝地集成到你的 Gin/gRPC 服务中，打包成一个极小的 Docker 镜像，部署到任何 K8s 集群。

这就是为什么它能霸榜 GitHub 的原因——它不是在教你如何更好地“调优 Prompt”，而是在教你如何用坚实的工程代码，去彻底终结那个不可控的“炼丹”时代。

Google的adk-go，就是那座连接 Gopher 工程世界与 AI Agent 智能世界的桥梁。

和我一起，从零开始“造”一个真正的 AI Agent

坦白说，ADK for Go 刚刚推出，市面上的教程几乎一片空白。文档虽有，但如何将其与真实的工程场景结合，如何理解其设计背后的权衡，如何避开那些必将遇到的“坑”——这些都需要有人去探索，去趟路。

所以，我决定做这件事。

我将以一个“学伴”和“探索者”的身份，推出我的全新付费微专栏：

《Google ADK 实战：用 Go 构建可靠的AI Agent》

在这个专栏里，我不会扮演一个无所不知的专家。相反，我会将我从零开始学习、实践、踩坑、顿悟的全过程，毫无保留地分享给你。

我们将一起，手把手地、从一个空 main.go 文件开始，完成一次令人兴奋的创造之旅：

• 第 1-2 讲：思维转变与灵魂注入
  我们将彻底理解“代码优先”的哲学，拆解adk-go，了解其中的概念、架构和核心组件，并亲手定义出第一个实现了 agent.Agent 核心接口的智能体。

• 第 3 讲：为 Agent 插上“手臂”： 让你的Agent能调用任何Go函数，像操作自己的手脚一样自如
  我们将学会 ADK 的“魔法”函数 functiontool.New，将一个普通的 Go 函数，零成本地转化为 Agent 可用的工具。

• 第 4 讲：赋予 Agent “双核记忆”
  我们将深入 session（短期记忆）和 memory（长期记忆），让我们的 Agent 能够理解上下文，并记起与你的历史交互。

• 第 5 讲：从“单兵”到“军团”： 构建一个懂分工、会协作的Agent团队，自动化完成复杂任务
  我们将学习 workflowagents，通过编排多个专家 Agent，构建一个强大的“代码生成-审查-重构”自动化流水线。

• 第 6 讲：从“原型”到“产品”
  我们将为 Agent 建立科学的评估体系，并最终将其打包成 Docker 镜像，部署到通用的 Kubernetes 环境中。

学完这个专栏，你将收获的，不仅是一个能跑起来的酷炫 AI 项目，更是一套可复用的、工程化的 AI Agent 构建方法论，以及在 AI 新浪潮中，属于我们 Gopher 的那份自信和底气。

加入这场 Gopher 的 AI 工程化之旅

这个微专栏，是我为你，也为我自己准备的一份“AI 时代 Gopher 生存指南”。它凝聚了我对 Go 工程哲学的理解，和我对 AI Agent 未来的全部热情。

微专栏共 6 篇深度长文，每一篇都是我亲手实践、细节满满的 step-by-step “航海日志”。

我没有设定一个高昂的价格，而是希望与更多志同道合的 Gopher 一起探索。所以，订阅这份专栏，仅需你一杯咖啡的诚意。

花一杯咖啡的时间，你或许能得到片刻的清醒；而用同样的价格投入到这里，我希望能为你带来一次思维的升级和技能的跃迁。

点击这里，或扫描二维码，立即加入。

让我们一起，用代码，构建智能。

P.S. 如果你对 AI Agent、Go 语言或者这个微专栏有任何问题，欢迎在评论区留言，我们一起交流探讨！

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

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

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

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

© 2025, bigwhite. 版权所有.

本文永久链接 – https://tonybai.com/2025/11/21/why-go-is-quietly-doing-what-rust-couldnt-staying-simple

大家好，我是Tony Bai。

近日，一篇题为《为什么 Zig 在悄悄地做 Rust 做不到的事：保持简单》的文章在开发者社区引发了热议。文章以其辛辣、富有煽动性的文风，将 Zig 描绘成 Rust 复杂性的“解毒剂”，是“一个终于接受了心理治疗的 C 项目”，并引发了关于“简单性”与“安全性”的深刻辩论。

这不禁让我们——作为 Go 社区的观察者——产生了一个有趣的想法：如果我们将文中的主角 Zig，完全替换为 Go，这篇文章的论点是否依然成立？

Go 语言，在其诞生之初，同样被视为对 C++ 等语言复杂性的“反叛”。它与 Zig 在追求编译速度、二进制简洁性以及“显式优于隐式”的哲学上，有着惊人的相似之处。

于是，我们进行了一次大胆的“思想实验”：在保留原文犀利风格和核心论证结构的前提下，将所有关于 Zig 的部分都替换为 Go，并将代码示例“翻译”为地道的 Go 代码。

这并非意在挑起 Go 与 Rust 之间的“战争”，而是希望通过这样一次“角色扮演”，从一个全新的、极具张力的视角，来重新审视 Go 语言的设计哲学，以及它在现代编程语言光谱中所占据的那个独特、宝贵且时常被误解的位置。

以下，便是这次思想实验的成果。各位小伙伴儿品一品，这样替换后，是不是不仅完美地道出了 Go 在“简单”与“显式”上的坚持，更说出了许多 Gopher 心里想说，却又不好意思直接对 Rust 爱好者说出口的‘真心话’？

Rust 对安全性大声疾呼。Go 只是把它构建了进去——没有那些仪式感、没有那些说教、也没有那 15 分钟的编译时间。

引子

我第一次写 Go 代码的时候，忍不住笑出声来。不是因为它好笑——而是因为我不敢相信，在现代编程世界里，还存在着如此……安静的东西。

在与 Rust “搏斗”多年之后——那门承诺将我们从 C 的苦海中拯救出来，却不知怎的变成了一场性格测试的语言——Go 感觉就像是 Rust 霓虹闪烁的都市中心里，一间温暖、极简的小木屋。

而这，正是关键所在。

Go 并非试图成为未来。它只是想保持理智。

Rust 承诺了天堂，却给了我们一堆文书工作

还记得那股炒作的热潮吗？Rust 是“C 语言杀手”，是内存安全的“弥赛亚”，是系统编程的“救世主”。

平心而论，Rust 确实……算是兑现了。你可以写出快如闪电的安全代码——在你向借用检查器献祭了三只山羊和整个周末的心智健全之后。

你看着这样的代码：

// Rust
fn main() {
    let mut data = vec![1, 2, 3];
    let ref1 = &data;
    data.push(4); // 借用检查器：“凡人，你不能这么做。”
    println!("{:?}", ref1);
}

你会想，为什么？为什么我的编译器听起来像我的前任在解释情感边界？

Rust 像一个严厉的治疗师一样教你所有权。而 Go 呢，只是耸耸肩说：“你搞坏了，你修好它。”

这就是哲学的分水岭。Rust 假设你不可信。Go 假设你是个成年人。

Rust 的才华毋庸置疑——安全、并发、无畏的重构。但它也……让人筋疲力尽。那些仪式感。那些工具链。那种将过度工程伪装成纯粹性的文化。

而 Go 呢，穿着连帽衫，拿着半个三明治出现，说：“嘿，想不想直接把该死的二进制文件构建出来？”

无聊之美

这是大多数人忽略的一点：简单不是一个特性。它是一种反叛。

Go 看起来很无聊。感觉也很无聊。读起来就像一个终于接受了心理治疗的 C 项目。

// Go
package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

就是这样。没有宏。没有 build.rs。没有 Cargo 尖叫着说哪个 crate 过期了。

仅仅。一个。编译器。

其底层呢？一个能让你团队喜极而泣的设计：

• 没有隐藏的控制流。
• 没有未定义行为。
• ** 没有运行时的“惊吓” (No runtime surprises)**。（即，没有像 JIT 或复杂后台进程那样，会产生不可预测行为的“魔法”运行时）
• 一个像钟表一样精确工作的确定性构建系统。

你可以去读 Go 编译器的源码，并且真的能读懂它。你去试试读 Rust 的编译器源码，那你需要咖啡因、心理治疗和一个祈祷小组。

Go 不性感。它很实用。它是那种你会忘记你正在使用的语言——而这，是最高的赞美。

Rust 扩展了代码库，Go 扩展了人类

说实话吧——Rust 最大的优点也是它最大的诅咒：它迫使你思考。不停地思考。

每一行代码都是一场关于生命周期、可变性和宇宙正义的哲学辩论。

Go 呢？Go 就像是说：“嘿，这是内存。别把自己捅了就行。” (笔者注：Go是GC语言，这句直接替换zig后的表达可能不是很契合)

这很重要。尤其是在团队中。

Rust 感觉像学术界——人们在 Slack 上辩论着 monad，而功能的截止日期却在悄悄溜走。Go 感觉像那个穿着脏兮兮运动鞋、代码却能跑起来的初创公司工程师。

在 Swiggy 这样的规模下，Go 取代了 Java 后端，因为它扩展了开发团队。Go 也许正在悄悄地为系统编程做同样的事情——不是因为它“更好”，而是因为它更人性化。 (笔者注：由于有特定背景局限，这里将zig替换为Go后可能也不是很契合了)

你不需要一块精神白板来在脑中记住 12 条借用规则。你只需要……写。

讽刺的转折：Go 才是 Rust 假装要成为的样子

Rust 将自己营销为“安全的系统编程”。但它实际上是——一个系统框架。

Cargo、crates、宏、过程魔法——这是一个生态系统，而不是一门语言。华丽，但沉重。

Go 把所有这些都剥离了。

没有依赖爆炸。没有语言版本混乱。没有每夜构建的轮盘赌。

最关键的是——Go 的构建系统是如此集成，如此具有确定性，以至于整个 CI/CD 的设置都感觉更清爽了。

Rust 像一座现代大教堂一样构建。Go 像一条工具腰带一样构建。

“Go 不试图保护你。它试图赋予你力量。”

这就是那场安静的反叛。Go 相信你知道自己在做什么——它只给你足够的绳子让你把事情绑在一起，而不是让你上吊。

而讽刺的是什么？Go 中那些“不安全”的部分，在实践中往往最终更安全，因为你能看到一切。没有魔法。没有语法糖。只有原始的意图。

当炒作退去，简单性胜出

每个技术周期都以同样的方式结束。

炒作机器火力全开。Medium 上的文章成倍增加。Meme 如潮水般涌来。然后有一天——凌晨两点，生产环境着火了，你只想知道为什么该死的二进制文件崩溃了。

Rust 给了你安全。但 Go 给了你清晰。

// Go
package main

import (
    "fmt"
    "os"
)

func main() {
    file, err := os.Create("output.txt")
    if err != nil {
        // 你能清晰地看到错误处理
        panic(err)
    }
    defer file.Close()

    _, err = file.WriteString("Explicit is better than implicit.")
    if err != nil {
        panic(err)
    }
}

你简直可以追踪到每一个字节。没有隐藏的分配器。没有神秘之处。

这正是老派 C 开发者所怀念的那种控制感——但现代开发者却忘记了自己也需要这种感觉。

这场安静革命的教训

• 简单是一种权力。你的语言越可预测，你付出的认知税就越少。
• 安全不是舒适。Rust 让你感到安全，但筋疲力尽。Go 让你感到暴露，但一切尽在掌握。
• 你不需要另一个抽象。你需要更少的抽象。
• 有时，无聊会赢。因为无聊的东西能扩展、能调试、能交付。

最后的思考

Rust 将继续演进。它配得上它的王座。但在某个地方，有一支小团队正在用 Go 构建——没有炒作，没有技术大会演讲，没有花哨的市场营销。

只是在悄悄地编写着那些永不崩溃、编译只需几秒、在生产环境中如幽灵般运行的干净的二进制文件。

这就是没人预见到的转折。Go 并非在与 Rust 的未来竞争。它在复活编程的过去——我们早已遗忘的那些美好部分。

而且，也许，仅仅是也许，这就是它最终获胜的方式。

资料链接：https://freedium-mirror.cfd/@daxx5/why-zig-is-quietly-doing-what-rust-couldnt-staying-simple-a47f86b3a58a

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

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

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

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

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

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

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

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

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

© 2025, bigwhite. 版权所有.