本文永久链接 – https://tonybai.com/2025/04/28/go-ecosystem

大家好，我是Tony Bai。

最近，Go社区里的一则消息引发了不少关注和讨论：广受欢迎的 go-yaml 库作者 Gustavo Niemeyer 宣布将项目正式标记为“归档(archived)”。这不仅让很多依赖该库的项目需要考虑迁移，也恰好触动了许多 Gopher 心中的一根弦。

就像我的知识星球“Go & AI 精进营”里的星友 Howe 所提出的那个精彩问题一样：

“白老师…其实会发现，很多 Go 开源工具是没有持续更新维护的好像，不像 Java 那种，有一些框架甚至会有专门的组织去维护，比如 Spring，所以从这点来看，Go 的生态发展就比较担忧了，不知道会不会多虑了…”

go-yaml 的归档，似乎成了这个担忧的一个现实注脚。一个维护了十多年、被广泛使用的基础库，说停就停了，这是否预示着 Go 的开源生态存在系统性的脆弱？我们是否真的应该为此感到焦虑？

在下结论之前，我们不妨先看看 go-yaml 作者 Gustavo 本人的说明，这其中透露的信息远比“停止维护”四个字要丰富得多：

“这是我最早的 Go 项目之一…维护了十多年…可惜的是…个人和工作空闲时间都减少了…我原本希望通过将其转移到资源更丰富的专业团队…但最终也没能如愿…我也不能直接把维护工作‘交给’某个人或一个小团队，因为项目很可能会再次陷入无人维护、不稳定甚至被滥用的状态。…很抱歉。”

Gustavo 的话语中，我们读到的不是草率的放弃，而是一个资深开源贡献者长达十年的坚持、后期的力不从心、以及对项目质量和用户负责任的审慎态度。这恰恰揭示了许多 Go 开源项目（乃至整个开源世界）的一个普遍现实：大量项目是由个人开发者或小团队利用业余时间驱动的，他们的热情和精力是项目持续发展的关键，但也可能成为单点故障。

在深入探讨之前，我们首先要向 go-yaml 的作者 Gustavo Niemeyer 致以诚挚的感谢。他凭借个人的热情和努力，将这个项目从 2010 年的圣诞假期启动，并坚持维护了超过十年之久，为 Go 社区贡献了一个极其重要的基础库。我们理解并尊重他因个人时间精力变化而做出归档的决定。需要明确的是，本文无意指摘这一事件本身，而是希望借此契机，与大家一同审视和思考 Go 开源生态系统的韧性与我们应如何看待其发展模式。

Go 生态模式 vs Java (Spring) 模式：不同而非优劣

Howe 的问题提到了 Java Spring，这是一个很好的对比参照。以 Spring 为代表的许多 Java 核心框架，背后往往有强大的商业公司或成熟的基金会提供组织化保障。这种模式无疑提供了更高的确定性和资源投入，让使用者更有“安全感”。

相比之下，Go 的生态呈现出不同的特点：

1. 强大的标准库 “自带电池”: Go 从设计之初就内置了极其丰富且高质量的标准库。
2. 社区驱动，“小而美”哲学: Go 社区倾向于构建更小、更专注、职责单一的库。
3. 公司开源与社区贡献并存: Go 生态中，既有大量个人维护的优秀项目，也有 Google、HashiCorp、Uber 等公司开源并积极维护的核心库。
4. Go Modules 的作用: Go Modules 让依赖管理变得清晰，发现、评估和替换依赖库也相对容易。

go-yaml 事件：是“脆弱”的证明，还是“韧性”的体现？

go-yaml 的归档确实暴露了依赖个人维护者带来的风险（“脆弱”）。但我们更应该看到的是生态系统的应对和演化（“韧性”）：

• 现实更复杂 – K8s 的硬分叉: 近期 Kubernetes 社区关于 kubernetes-sigs/yaml 的讨论 (Issue #129) 揭示了一个更深层的事实。原来，Kubernetes 社区早在 2023 年就已经对 go-yaml 的 v2 和 v3 版本进行了硬分叉 (hard fork)，并将其纳入 sigs.k8s.io/yaml 进行自主维护。他们这样做是为了获得完全的掌控力、保障稳定性，并确保其行为符合 Kubernetes 对 JSON 兼容性的特定需求。这表明，像 Kubernetes 这样的重量级玩家，在核心依赖面临不确定性或不完全满足需求时，会选择更“硬核”的方式来确保自身生态的稳定，而不是简单跟随上游的推荐。这既是生态韧性（有能力采取极端措施自我保护）的体现，也增加了生态的复杂性。
• 替代品与多元选择: 上述 K8s 的 Issue 中也提到了另一个正在崛起的 YAML 库 goccy/go-yaml，并指出 Kubernetes 之外的 Go 生态似乎正向其靠拢。这进一步说明，Go 生态并非只有一条路可走，而是充满了动态的选择和竞争。当一个库出现维护问题或不能满足所有需求时，社区往往会涌现出不同的解决方案。
• 社区的自愈能力: 无论是官方推荐的继任者、重量级玩家的硬分叉，还是社区涌现的新替代品，都展示了 Go 生态在面临挑战时的自我修复和演化能力。Go Modules 在这种多元选择并存的情况下，为管理依赖提供了基础工具。

与此同时，2023年Go官方团队曾对于“是否应将encoding/yaml加入标准库”的讨论（可见于GitHub Issue #61023）也为我们理解这一现状提供了官方视角。 尽管 YAML 在 Go 生态（尤其是 K8s、Helm 等领域）中应用极为广泛，且社区多次呼吁将其纳入标准库，但 Go 核心团队（包括 Russ Cox 本人）最终以 “不可行 (infeasible)” 拒绝了该提议。

拒绝的核心原因并非不认可 YAML 的重要性，而是其内在的巨大复杂性。 RSC 指出，YAML 规范远比 JSON 甚至 XML 复杂得多，实现一个完整、健壮且能长期维护的 YAML 解析器超出了当前 Go 团队的实际能力范围。尝试定义和实现一个“官方子集”同样困难重重，且可能导致更多的兼容性问题（encoding/xml 的前车之鉴也被提及）。

更关键的是，Go 团队明确认可并推荐使用 gopkg.in/yaml.v3(即go-yaml/yaml) 作为 Go 生态中事实上的标准 YAML 库。 这再次印证了 Go 生态的韧性不仅体现在硬分叉或新库涌现上，也体现在社区能够围绕一个高质量的第三方库（即便它依赖个人维护者）形成广泛共识，并由官方背书推荐。这种模式，虽然不如标准库那样“保险”，但也是 Go 生态现阶段运作的重要特征。

我们是否多虑了？如何获得“生态安全感”？

担忧是合理的，但过度焦虑则不必。Go 在云原生等领域的成功，本身就依赖于其生态系统的支撑。关键在于，作为 Gopher，我们该如何在这种生态模式下获得“安全感”？

1. 尽职调查，深度了解: 在选择依赖时，需要更深入地了解：
   • 它实际依赖的是哪个底层实现？（尤其是在有包装库或 fork 的情况下，如 sigs.k8s.io/yaml）
   • 使用 go mod graph, go mod why 等工具，厘清直接和间接依赖。意识到像 K8s 生态那样，即使切换了直接依赖，间接依赖可能仍然存在（比如对 gopkg.in/yaml.v3 的依赖）。
   • 评估库的维护活跃度、背后力量、社区声誉、测试与文档。
2. 拥抱标准库: 尽可能优先使用标准库提供的功能。
3. 关注依赖更新: 定期检查依赖库的状态，关注安全更新 (govulncheck)。
4. 制定预案: 对核心依赖，思考是否有替代方案？当依赖出现问题时，是否有能力 fork 并自行维护？
5. 参与和贡献: 积极参与社区，为依赖的库贡献力量，是提升生态韧性的最有效方式。

小结

go-yaml 的归档及其后续讨论（特别是 K8s 的硬分叉行为和 goccy/go-yaml 的兴起）给我们上了一堂生动的 Go 生态实践课。它揭示了这个生态系统并非只有简单的“推荐路径”，而是充满了基于现实需求的pragmatic choices（务实选择），有时甚至是“硬核”的自我保护机制。

Go 的生态也许不像某些老牌语言那样拥有高度统一、组织化支持的核心框架，它更像一个充满活力、快速迭代、有时甚至略显“野蛮”生长的雨林。这里有大树（标准库、大公司开源项目），也有藤蔓（各种小而美的库），还有适应特定环境的变种（如 K8s 的硬分叉）。

作为 Gopher，我们需要理解并适应这种真实世界的复杂性，用更审慎的态度选择依赖，用更积极的心态参与社区，共同塑造一个更健壮、但也承认多元选择的 Go 生态。

与其过度担忧，不如积极拥抱，用更专业的眼光审视依赖，用更主动的姿态参与贡献。Go 生态的未来，掌握在每一个 Gopher 手中。

那么，未来 YAML 是否还有机会进入Go标准库呢？Go团队推荐的go-yaml/yaml的归档为这件事撬开了一丝丝缝隙，可能更大的难度在于yaml规范的复杂性本身，不过现在我们也可以小小期待一下!

你对 Go 的开源生态有何看法？在项目中遇到过类似 go-yaml 的情况吗？你是如何应对的？欢迎在评论区分享你的经验和思考！

深入探讨，加入我们！

今天讨论的 Go 开源生态话题，只是冰山一角。在我的知识星球 “Go & AI 精进营” 里，我们经常就这类关乎 Go 开发者切身利益、技术选型、生态趋势等话题进行更深入、更即时的交流和碰撞。

如果你想：

• 与我和更多资深 Gopher 一起探讨 Go 的最佳实践与挑战；
• 第一时间获取 Go 与 AI 结合的前沿资讯和实战案例；
• 提出你在学习和工作中遇到的具体问题并获得解答；

欢迎扫描下方二维码加入星球，和我们一起精进！

参考资料

• go-yaml – https://github.com/go-yaml/yaml
• github.com/go-yaml/yaml is archived] – https://github.com/kubernetes-sigs/yaml/issues/129
• proposal: encoding/yaml: Add YAML support in the standard library – https://github.com/golang/go/issues/61023

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

本文永久链接 – https://tonybai.com/2025/04/27/rob-pike-on-bloat

大家好，我是Tony Bai。

今年年初，Go语言之父、UTF-8编码的发明者Rob Pike的一篇题为”On Bloat”（关于膨胀）的演讲幻灯片(在2024年下旬做的)在技术圈，尤其是在Hacker News(以下简称HN)上，引发了相当热烈的讨论。Pike作为业界泰斗，其对当前软件开发中普遍存在的“膨胀”现象的犀利批评，以及对依赖管理、软件分层等问题的深刻担忧，无疑戳中了许多开发者的痛点。

HN上的讨论更是五花八门，开发者们纷纷从自身经历出发，探讨“膨胀”的定义、成因和后果。有人认为膨胀是“层层叠加的间接性”导致简单修改寸步难行；有人认为是“不必要的功能堆砌”；还有人归咎于“失控的依赖树”和“缺乏纪律的开发文化”。

那么，Rob Pike究竟在“抱怨”什么？他指出的软件膨胀根源有哪些？而作为我们Gopher，Go语言的设计哲学和工具链，能否为我们从纯技术层面提供对抗膨胀的“解药”呢？今天，我们就结合Pike的演讲精髓和HN的热议，深入聊聊软件膨胀的四大根源，并从Go的视角尝试寻找一下应对之道。

“膨胀”的真相：远不止代码大小和运行速度

在深入探讨根源之前，我们需要认识到，“膨胀”并不止是字面意义上我们理解的最终编译产物的大小或者应用的运行速度慢，Pike的观点和HN讨论中的“软件膨胀”体现在多个维度：

• 复杂性失控： 过度的抽象层次、复杂的依赖关系、难以理解的代码路径，使得维护和迭代变得异常困难。
• 维护成本剧增： 添加新功能的长期维护成本（包括理解、测试、修复Bug、处理兼容性）远超初次实现的成本，但往往被低估。
• 不可预测性与脆弱性： 庞大且快速变化的依赖树使得我们几乎无法完全理解和掌控软件的实际构成和行为，任何更新都可能引入未知风险。

下面我们具体看看Pike指出的“膨胀”几个核心根源：

根源一：特性 (Features) —— “有用”不等于“值得”

Pike 指出，我们不断地为产品添加特性，以使其“更好”。但所有特性都会增加复杂性和成本，而维护成本是最大的那部分，远超初次实现。他警示我们要注意“有用谬论” —— 并非所有“有用”的功能都值得我们付出长期的维护代价。

HN讨论也印证了这一点：功能冗余、为了匹配竞品或满足某个高层“拍脑袋”的想法而添加功能、甚至开发者为了个人晋升而开发复杂功能的现象屡见不鲜。

技术层面：Go的“解药”在哪？

• 简洁哲学： Go从设计之初就强调“少即是多”，鼓励用简单的原语组合解决问题，天然地抵制不必要的复杂性。
• 强大的标准库： Go 提供了功能丰富且高质量的标准库，覆盖了网络、并发、加解密、I/O 等众多领域，减少了对外部特性库的依赖。很多时候，“自己动手，丰衣足食”（使用标准库）比引入一个庞大的外部框架更符合Go的风格。
• 关注工程效率： Go的设计目标之一是提高软件开发（尤其是大型项目）的工程效率和可维护性，这促使Go社区更关注代码的清晰度和长期成本。

注：技术层面包括语言、工具以及设计思路和方法。

根源二：分层 (Layering) —— 在错误的层级“打补丁”

Pike 认为，现代软件层层叠加（硬件 -> 内核 -> 运行时 -> 框架 -> 应用代码），当出现问题时，我们太容易在更高的层级通过包装（wrap）来“修复”问题，而不是深入底层真正解决它。这导致了层层叠叠的“创可贴”，增加了复杂性和维护难度。他列举了ChromeOS文件App的例子，并强调要在正确的层级实现功能和修复。

在HN的讨论中，有开发者描述的修改按钮颜色需要穿透17个文件和多个抽象层的例子，正是这种“错误分层”或“过度抽象”的生动体现。

技术层面：Go的“解药”在哪？

• 小接口哲学： Go 鼓励定义小而专注的接口，这使得组件之间的依赖更清晰、更松耦合。当问题出现时，更容易定位到具体的接口实现层去修复，而不是在外部层层包装。
• 组合优于继承： Go 通过组合（struct embedding）而非继承来实现代码复用，避免了深度继承带来的复杂性和脆弱性，使得在“正确层级”修改代码更易操作。
• 显式错误处理： if err != nil 的模式强制开发者在调用点处理错误，使得问题更难被“隐藏”到上层去统一“包装”处理，鼓励在错误发生的源头附近解决或添加上下文。

根源三：依赖 (Dependencies) —— 看不见的“冰山”

这是Pike演讲中着墨最多、也最为忧虑的一点。他用数据（NPM 包平均依赖 115 个其他包，每天 1/4 的依赖解析发生变化）和实例（Kubernetes 的复杂依赖图）强调：

• 现代软件依赖数量惊人且变化极快。
• 我们几乎不可能完全理解自己项目的所有直接和间接依赖。
• 依赖中隐藏着巨大的维护成本、Bug 和安全风险。
• 简单的 npm update 或 audit 无法解决根本问题。

他强烈建议要理解依赖的成本，严格、定期地审视依赖树，并推荐了 deps.dev 这样的工具。

HN 社区对此深有同感，纷纷吐槽“为了一个函数引入整个库”、“脆弱的传递性依赖”、“供应链安全”等问题，并呼唤更好的依赖分析工具。

技术层面：Go的“解药”在哪？

• Go Modules： 相比 NPM 等包管理器，Go Modules 提供了相对更好的依赖管理机制，包括语义化版本控制、go.sum 校验和、最小版本选择 (MVS) 等，提高了依赖的可预测性和安全性，但也要注意Go module并非完美。
• 强大的标准库： 这是 Go 对抗依赖泛滥的最有力武器。很多功能可以直接使用标准库，避免引入外部依赖。
• 社区文化： Go 社区相对而言更推崇稳定性和较少的依赖。引入一个大型框架或过多的外部库在 Go 社区通常需要更充分的理由。
• 工具支持： Go 提供了 go mod graph, go mod why 等命令，可以帮助开发者理解依赖关系。结合 deps.dev，可以在一定程度上实践 Pike 的建议。

根源四：开源模式 (Open Source Development) —— “大门敞开” vs “严格把关”

Pike 对比了两种开源开发模式：

• “真正的开源方式” (The true open source way): 接受一切贡献 (Accept everything that comes)。他认为这是膨胀和 Bug 的巨大来源。
• 更好的方式： 设立严格的代码质量、标准、评审、测试、贡献者审查等“门槛”，对允许合入的内容有标准。这种方式维护成本低得多。

他暗示 Go 项目本身更倾向于后者，强调“先做好再提交”（make it good before checking it in）。可能很多Gopher也感受到了这一点，Go项目本身对代码质量的review非常严格，这一定程度上也“延缓”了一些新特性进入Go的时间点。

HN 的讨论中也涉及了类似 “Bazaar vs Cathedral” 的模式对比，但观点更加复杂，认为现实中的项目往往处于两者之间的某个位置，并且“完全不接受外部贡献”也并非良策。

技术层面：Go的“解药”在哪？

• Go 自身的开发模式： Go 语言本身（由 Google 主导）的开发流程相对严谨，对代码质量和向后兼容性有较高要求，可以看作是“严格把关”模式的体现。
• 标准库的设计： Go 标准库的设计精良、接口稳定，为开发者提供了一个高质量的基础平台，减少了对外部“随意贡献”的依赖。
• 社区项目实践： 观察 Go 社区一些知名的开源项目，其贡献流程和代码标准通常也比较严格。

反思与现实：Go 也非万能，“警惕与纪律”仍是关键

虽然 Go 的设计哲学和工具链在对抗软件膨胀方面提供了许多“天然优势”和“解药”，但我们必须清醒地认识到，Go 语言本身并不能完全免疫膨胀。

正如 Pike 在其“建议”(Advice) 中反复强调的，以及 HN 讨论中部分开发者指出的，最终软件的质量很大程度上取决于开发者和团队的“警惕与纪律” (vigilance and discipline)：

• 我们是否真正理解并避免了增加不相称成本的特性？
• 我们是否努力在正确的层级解决问题？
• 我们是否审慎地评估和管理了每一个依赖？
• 我们是否坚持了高标准的开发和评审流程？

如果缺乏这些，即使使用 Go，项目同样可能变得臃肿、复杂和难以维护。同时，HN 讨论也提醒我们，软件膨胀背后还有更深层次的组织、文化和经济因素，这些往往超出了单纯的技术和开发者纪律所能解决的范畴。

小结：拥抱 Go 的简洁，但需务实前行

Rob Pike 的“抱怨”为我们敲响了警钟，Hacker News 的热议则展现了软件膨胀问题的复杂性和普遍性。它确实是我们在工程实践中需要持续对抗的“熵增”现象。

Go 语言以其简洁、显式、组合的设计哲学，以及强大的标准库和相对稳健的依赖管理，在技术层面上，为我们提供了对抗膨胀的有力武器。理解并拥抱这些 Go 的“基因”，无疑能在一定程度上帮助我们构建更健康、更可持续的软件系统。

当然，Pike 的观点也并非金科玉律。有批评者指出，他的视角可能带有一定的“NIH（非我发明）倾向”，并且存在两个关键的“盲点”：

1. 忽视了“不使用依赖”同样是巨大的技术债。 每一行自写的代码都需要永远维护。
2. 现实中的选择往往不是“使用依赖 vs 自己实现”，而是“使用依赖 vs 根本不做这个功能”。 面对复杂的合规要求（如 ADA、GDPR）、第三方集成或 FIPS 认证等，从零开始构建的成本（可能需要数百人年）往往让“自己实现”变得不切实际。为了让产品能够及时上线并满足用户（哪怕是 Pike 本人可能也在使用的“缓慢”网站）的需求，引入依赖和一定的“膨胀”有时是必要且务实的选择。

注：“NIH（非我发明）倾向”是一种心理现象，指的是人们对他人提出的想法或创新持有偏见，通常因为这些想法不是自己发明的。这种倾向使得人们倾向于低估或拒绝其他人的创意，尽管这些创意可能是有价值的。

这种批评也提醒了我们，虽然 Pike 对简洁和纪律的呼吁值得我们高度重视，但在真实的商业环境和复杂的工程约束下，我们必须做出务实的权衡。纯粹的技术理想有时需要向现实妥协。

最终，我们每一位 Gopher 都需要在理解 Go 简洁之道的同时，保持批判性思维和务实态度。 在日常的每一个决策中，审慎地权衡简单与复杂、理想与现实、引入依赖与自主掌控，才能在这场与“膨胀”的持久战中，找到最适合我们项目和团队的平衡点，交付真正有价值且可持续的软件。

你如何看待 Rob Pike 对软件膨胀的观点？你认为他的批评切中要害，还是忽视了现实的复杂性？欢迎在评论区分享你的思考与实践！

参考资料

• Rob Pike – On Bloat – https://docs.google.com/presentation/d/e/2PACX-1vSmIbSwh1_DXKEMU5YKgYpt5_b4yfOfpfEOKS5_cvtLdiHsX6zt-gNeisamRuCtDtCb2SbTafTI8V47/pub?slide=id.p
• HN：On Bloat – https://news.ycombinator.com/item?id=43045713
• Pike is wrong on bloat
• On Bloat – https://commandcenter.blogspot.com/2025/02/on-bloat-these-are-slides-from-talk-i.html

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