gomodule - Tony Bai

本文永久链接 – 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（非我发明）倾向”，并且存在两个关键的“盲点”：

忽视了“不使用依赖”同样是巨大的技术债。 每一行自写的代码都需要永远维护。
现实中的选择往往不是“使用依赖 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

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

本文永久链接 – https://tonybai.com/2025/03/28/go-mod-verify-tag

Go模块(module)在Go 1.11版本中引入，显著简化了依赖管理，使开发者能够通过go.mod文件明确声明和管理库依赖，支持语义版本控制，并提高了构建速度和可移植性。使得Go语言的依赖管理更加现代化和高效，提升了开发者的体验。

同时引入的校验和数据库 (sumdb) 也极大地增强了Go生态的依赖管理的确定性和安全性。然而，在模块作者发布新版本时，从本地代码库打上标签推送到代码托管平台，再到被Go Proxy和sumdb收录，这个过程中仍然存在一个微妙但关键的信任验证环节缺失。近期，Go团队接受了一项备受关注的提案(Issue #68669，旨在通过扩展go mod verify命令来弥补这一空白，为模块作者提供一种官方途径来验证他们本地的代码和标签确实与Go生态系统将收录的版本一致。在这一篇文章中，我就根据issue中的内容，来简单介绍一下这一新增安全机制的背景和运作原理。

注：该机制的提案刚刚被Accept，尚未确定在哪个版本落地，不过大概率是在Go 1.25版本中。

1. 问题背景：发布过程中的信任鸿沟

当前，Go开发者在发布一个新的模块版本时，通常的流程是：

在本地代码库完成开发和测试。
使用git tag (例如git tag v1.2.3) 创建版本标签。
使用git push –tags 将代码和标签推送到代码托管平台 (如 GitHub)。
等待Go Proxy (如proxy.golang.org) 拉取新版本，并将其信息提交给官方sumdb。

虽然sumdb保证了下游用户下载的模块代码未被篡改 (相对于sumdb中的记录)，但它无法保证sumdb中记录的版本就精确地是模块作者在本地打标签时所期望的版本。潜在的风险点包括：

代码托管平台被篡改: 拥有强制推送权限的攻击者可能在标签推送后修改了标签指向的提交。
代码托管平台自身问题: 平台自身可能存在Bug或被攻击，导致返回给Go Proxy的代码与原始标签不符。
Go Proxy或sumdb问题: 尽管概率较低，但中间环节也可能存在问题。

正如提案贡献者和Go核心团队成员在讨论中指出的，目前缺少一个简单直接的方式让模块作者确认：“我本地标记为v1.2.3的代码，是否就是全世界通过Go工具链获取到的那个v1.2.3？”。

2. 提案核心：go mod verify -tag

为了解决这个问题，提案#68669建议为现有的go mod verify命令增加一个新的-tag标志。go mod verify命令目前用于检查本地缓存的依赖项是否被修改，而新的-tag标志则将关注点转向了当前模块本身。

2.1 拟议的功能

$go mod verify -tag=<value>

其中可以是：

: 一个具体的 Git 标签，例如v1.2.3。命令将检查本地仓库中该标签对应的代码树，计算其哈希，并与sumdb中记录的该版本的哈希进行比对。
latest: 检查本地仓库中最新的Git标签。
all: 检查本地仓库中所有的Git标签。

2.2 核心价值与使用场景

发布后验证 (主要场景)：这是该提案最核心的预期用途。模块作者在推送标签后，可以立即运行此命令来确认他们的代码已经“安全”地进入了Go的模块分发体系，且内容无误。

# 假设已完成开发
$git tag v1.2.3
$git push origin v1.2.3 # 或 git push --tags

# 关键一步：验证刚推送的标签
$go mod verify -tag=v1.2.3

这个操作还有一个重要的副作用：如果v1.2.3 尚未被Go Proxy和sumdb收录，运行go mod verify -tag=v1.2.3 会触发Go工具链去查询这个版本，从而加速它被Go生态系统发现和记录的过程，同时完成验证。

安全审计与代码审查: 当需要对某个模块的特定版本进行安全审计或深入的代码审查时，可以使用此命令验证本地检出的代码副本确实是sumdb中记录的那个“官方”版本，而不是可能已被篡改的某个代码托管平台上的版本。

3 社区讨论与设计考量

在提案的讨论过程中，社区也探讨了该功能是否应该放在go mod verify命令下，因为它与验证依赖项的现有功能有所不同。一些替代方案被提出，例如创建一个新的子命令go mod verify-tags或go mod proxy -check=TAG等。

最终，提案审查小组倾向于并接受了将此功能作为go mod verify的扩展，主要是考虑到：

概念一致性: 虽然对象不同（当前模块 vs 依赖项），但核心都是进行某种形式的“验证” (verify)。
避免命令扩散: 增加标志比增加新子命令更轻量。
文档可更新: 可以通过更新go mod verify 的文档来清晰地说明其扩展后的功能范围。

需要注意的是，该提案主要解决的是模块作者验证自身发布的问题，与验证项目依赖项是否在源头（如GitHub）被篡改（例如Issue #66653讨论的情况）是不同的问题，尽管它们都属于Go模块供应链安全的一部分。

4. 小结

go mod verify -tag提案的接受是Go模块生态系统在安全性方面迈出的又一重要步伐。它为模块作者提供了一个简单、官方的工具来关闭发布流程中的一个关键信任缺口，增强了从代码编写到模块分发的端到端完整性保证。

虽然具体的实现细节仍在进行中 (由 Issue #68669 跟踪)，但Go开发者可以期待在未来的Go版本中获得这一实用功能。这不仅有助于提升个别模块的安全性，也将进一步巩固整个Go生态系统的供应链安全基础。

5. 参考资料

Go Issue #68669: https://github.com/golang/go/issues/68669 – https://github.com/golang/go/issues/68669
相关变更CL: https://go.dev/cl/596097 – https://go.dev/cl/596097

Gopher部落知识星球在2025年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。并且，2025年将在星球首发“Go陷阱与缺陷”和“Go原理课”专栏！此外，我们还会加强星友之间的交流和互动。欢迎大家踊跃提问，分享心得，讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落，享受coding的快乐! 欢迎大家踊跃加入！

img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格6$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式：