本文永久链接 – https://tonybai.com/2025/05/13/go-prefer-less-framework

大家好，我是 Tony Bai。

Go 语言自诞生以来，就以其简洁、高效和强大的并发模型赢得了全球开发者的青睐。它的设计者们，包括 Rob Pike、Ken Thompson 这些计算机界的巨匠，在创造 Go 的时候，秉持了一种鲜明的风格：“少即是多” (Less is More)。这不仅体现在其精简的语法和关键字上，更深刻地影响了 Go 社区对于“框架” (Frameworks) 的普遍态度。

虽然 Go 官方从未明确宣称“轻框架或无框架”是其核心哲学，但从其设计选择——如强大的标准库、鼓励组合优于继承——以及社区早期的主流声音来看，Go 显著地倾向于“轻框架”，或者说“反大型、侵入式框架”。

但这种在语言层面推崇的“轻盈”与“自由”，在实际的团队协作和大型项目开发中，究竟是解放生产力的“馈赠”，还是悄然套上了一层限制效率的“无形枷锁”？今天，我们就来探讨一下 Go 社区这种独特的“轻框架”理念。

“轻框架”的初心：拥抱简洁、掌控与标准库的力量

Go 社区对“轻框架”的偏爱，并非空穴来风，而是源于对传统大型框架某些弊端的回避，以及对 Go 自身优势的充分自信：

1. 对“重框架”的反思： Go 的设计者们深谙大型框架（如 Java Spring, Ruby on Rails 等早期版本）在提供便利的同时，也可能带来学习曲线陡峭、过度设计、灵活性受限、性能开销以及难以捉摸的“魔法”等问题。Go 倾向于让开发者更接近底层，更清晰地理解代码的执行路径。
2. 强大的标准库 “自带电池”： 这是 Go “轻框架”理念的底气所在。Go 标准库异常强大且全面，覆盖了网络、HTTP、JSON/XML 处理、加密、并发原语、测试等核心功能。许多在其他语言中需要依赖框架才能便捷实现的功能，Go 标准库直接提供，鼓励开发者首先“向内求”。
3. 组合优于继承，接口驱动设计： Go 语言本身的设计哲学鼓励通过组合小而专注的组件来构建复杂的系统，并通过接口实现解耦和多态。这种范式使得代码更易于理解、测试和维护，自然降低了对庞大、层级复杂的框架的需求。
4. 赋予开发者掌控权： “轻框架”意味着更少的隐藏逻辑和约定。开发者对代码的执行流程有更强的掌控感，这对于构建高性能、高可靠性的系统至关重要。
5. 鼓励针对性解决方案： Go 社区倾向于针对特定问题选择或构建小而美的库，而不是试图用一个“万能框架”解决所有问题。这促进了 Go 生态中大量高质量、专注的第三方库的涌现。

这种“轻框架”理念带来的益处显而易见：

• 学习曲线相对平缓： 开发者可以更快地掌握语言核心和标准库，而不必先学习一个庞大的框架体系。
• 高度灵活性： 开发者可以根据项目具体需求自由选择技术栈、架构模式和第三方库，不受框架的强约束。
• 性能透明且可控： 避免了大型框架可能引入的未知性能开销。
• 社区库的“专而精”： 催生了大量专注于解决特定问题的优秀第三方库，开发者可以像搭积木一样按需选用和组合。

对于许多追求极致性能、需要高度定制化、或者开发者经验丰富的场景，Go 的这种“轻框架”倾向无疑是一种解放。

当“轻盈”遭遇“团队”：浮现的挑战与“结构缺失”感

然而，当我们将视角从个体开发者的“自由创作”转向需要多人协作、长期维护的大型复杂系统时，Go 社区这种“轻框架”的理念，有时却可能带来新的挑战，让团队感受到一种“结构缺失”的困扰，甚至演变成效率瓶颈：

• 缺乏共享约定，导致“决策疲劳”与“风格各异”：

  • 项目结构“百花齐放”： 由于缺乏官方或广泛接受的项目布局“最佳实践”，不同团队甚至同一团队的不同项目都可能采用迥异的目录结构和代码组织方式。这无疑增加了新成员的上手门槛，也使得在项目间复用经验和代码变得困难。
  • 技术选型无尽的“圣战”： 路由用 Gin、Echo 还是 Chi？日志库选 Zap、Logrus 还是标准库 log 加封装？配置管理、数据库迁移、RPC 框架……由于缺乏“一锤定音”的框架推荐，团队常常需要在这些基础组件的选择、集成、封装和推广上耗费大量精力，进行无休止的调研、讨论甚至内部“站队”。
  • “重复发明轮子”的诱惑： 因为没有现成的、整合好的框架提供“全家桶”服务，团队在面对常见需求（如用户认证、权限管理、任务队列）时，更容易倾向于“自己动手，丰衣足食”，这可能导致大量功能相似但实现各异的内部“准轮子”，长期维护成本高昂。

• 基础设施与横切关注点的“重复建设”：

  • “胶水代码”与“基础设施代码”泛滥： 服务间的API调用、错误处理、链路追踪、监控埋点、配置加载、密钥管理等横切关注点，在缺乏统一框架抽象的情况下，往往需要在每个服务或模块中重复实现或集成，导致大量相似的“胶水代码”和“基础设施代码”。
  • DevOps 实践难以标准化： Dockerfile 的编写、CI/CD 流水线的配置、服务部署脚本等，如果每个项目都“各自为政”，难以形成统一、高效的 DevOps 实践，也增加了运维的复杂性。

• 团队协作与项目传承的隐形成本：

  • “雪花服务”林立，知识孤岛化： 每个服务都可能因为开发者的不同偏好和技术选型，演变成一个拥有独特“方言”和“习俗”的“小王国”。这使得代码复用、知识共享、人员在项目间的流动都变得更加困难。
  • 维护与交接的“噩梦”： 当一个高度定制化、缺乏统一规范的“轻框架”项目（甚至可以说是“无刻意设计的框架”）交到新人手中，或者核心开发者离职后，其理解难度和维护成本可能会急剧上升。
  • 团队规模扩大后的困境： 随着团队成员增多、项目复杂度上升，缺乏统一框架带来的沟通成本、集成成本和质量控制难度会指数级增长。

对于追求快速迭代、需要保持高度一致性、或者团队成员经验水平参差不齐的团队来说，Go 这种“过度自由”的“轻框架”理念，有时反而会成为一种负担。开发者可能会怀念在 Rails、Django 或 Spring Boot 这类成熟框架中那种“约定优于配置”、开箱即用的便利感。

实践中的平衡：在“轻盈”与“结构”间寻找智慧

面对 Go 社区“轻框架”的理念，以及它在团队协作中可能带来的挑战，我们并非束手无策。关键在于如何在享受其“轻盈”与“自由”的同时，有意识地为团队引入必要的“结构”与“秩序”：

• 建立团队内部的“强约定”与“最佳实践指南”：
  • 这是最核心的应对策略。即使 Go 官方不提供，团队内部也必须投入精力沉淀和推广一套自己的项目模板、代码规范（如 Uber Go Style Guide）、推荐库列表（形成内部“技术雷达”）、以及针对常见场景的架构模式和解决方案。
  • 通过严格的 Code Review、定期的技术分享、完善的内部文档，确保这些“内部标准”得到遵守和持续迭代。
• 拥抱“轻框架/微框架”和高质量的第三方库，形成“技术栈共识”：
  • Go 社区有大量优秀的、专注于解决特定问题的库（如 Gin/Echo 用于 Web 开发，GORM/sqlx 用于数据库交互，Zap/Logrus 用于日志等）。团队应在充分调研的基础上，选择并标准化一套适合自己的“技术全家桶”，并围绕它们构建开发模式，避免成员随意引入未经评估的库。
• 善用代码生成、脚手架与项目模板：
  • 针对常见的样板代码（如 API 接口定义、CRUD 操作、项目初始化），可以开发或引入代码生成工具（如 go-swagger, protoc-gen-go 等）和标准化的项目脚手架，提高开发效率，保证代码风格和结构的一致性。
• 强化架构设计能力，明确模块化与接口：
  • 在项目初期投入足够的时间进行良好的架构设计，明确服务边界、模块职责、数据模型和接口定义。清晰的架构是应对复杂性的基石，其重要性在“轻框架”环境下尤为突出。
  • 即使没有框架的强制约束，也要通过清晰的模块化和精心设计的接口来降低耦合，提高代码的可测试性和可维护性。
• 投资于平台工程与 DevOps 工具链：
  • 将基础设施的配置、部署、监控、日志收集等工作尽可能平台化、自动化，减少手动操作和人为错误。
  • 构建统一的 CI/CD 流水线，提供标准化的 Docker 镜像基础，推广基础设施即代码 (IaC) 的理念。
• 审慎评估并引入“有观点”的 Go 开发平台或框架 (如果真正适合)：
  • 近年来，Go 社区也开始涌现一些试图提供更完整解决方案、更具“观点”的开发平台或集成度更高的框架。它们可能内置了项目结构、服务发现、API 定义、部署等方面的约定。如果团队的痛点与这些工具试图解决的问题高度匹配，并且其引入成本和学习曲线可接受，可以考虑审慎评估和引入，它们或许能在 Go 的自由与团队所需的结构之间提供一种新的平衡点。

结语：自由的艺术在于自律与智慧的构建

Go 社区的“轻框架”理念，本质上是将设计的权力和责任更多地交还给了开发者和团队。这既是一种极大的自由，让我们能够摆脱不必要的束缚，打造出极致性能和高度定制化的系统；同时，它也是一种严峻的考验，要求我们具备更高的技术素养、更强的架构能力和更严格的团队自律。

• 对于经验丰富、纪律性强、且有能力驾驭这种自由的团队或个人，它可以释放出巨大的创造力和效率。
• 但对于缺乏经验、规范不足、或追求快速标准化的团队，这种“轻盈”也可能导致“结构缺失”的混乱和低效。

最终，Go 的“轻框架”理念是馈赠还是枷锁，并不取决于理念本身，而取决于使用它的人和团队如何理解这种理念，并有意识地、智慧地去构建适合自己的“秩序”与“结构”。在 Go 的世界里，真正的自由，或许并非随心所欲，而是通过团队的共同智慧和高度自律，构建起一套虽“轻”却不失章法的“隐形框架”，从而在享受简洁与高效的同时，也能保障项目的稳健、协作的顺畅与长远的发展。

你和你的团队在 Go 项目中是如何平衡自由与结构的？你们是否也曾感受到“轻框架”或“结构缺失”带来的困扰，又是如何解决的？欢迎在评论区分享你的宝贵经验和思考！

精进有道，更上层楼！

如果你已经掌握了 Go 语言的基础，渴望在语法强化、代码设计以及工程实践等方面获得更深层次的提升，那么我最新上架的Go语言进阶课程正是为你准备的！这门进阶课程，是我多年 Go 实战经验和深度思考的结晶，旨在帮助你突破瓶颈，从“会用 Go”迈向“精通 Go”。

扫描下方二维码，立即解锁你的 Go 语言进阶之路！

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

本文永久链接 – 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

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