本文永久链接 – https://tonybai.com/2025/10/15/go-archaeology-defer

大家好，我是Tony Bai。

在 Go 语言的所有关键字中，defer 无疑是最具特色和争议的之一。它以一种近乎“魔法”的方式，保证了资源清理逻辑的执行，极大地提升了代码的可读性和健壮性。f, _ := os.Open(“…”); defer f.Close() 这一行代码，几乎是所有 Gopher 的肌肉记忆。

然而，在这份优雅的背后，曾几何时，defer 却背负着“性能杀手”的恶名。在 Go 的历史长河中，无数资深开发者，包括标准库的维护者们，都曾被迫在代码的可维护性与极致性能之间做出痛苦的抉择，含泪删掉 defer 语句，换上丑陋但高效的手动 if err != nil 清理逻辑。

你是否好奇：

• defer 的早期实现究竟“慢”在哪里？为什么一个简单的函数调用会被放大数十倍的开销？
• 从 Go 1.13 到 Go 1.14，Go 团队究竟施展了怎样的“魔法”，让 defer 的性能提升了超过 10 倍，几乎达到了与直接调用函数相媲美的程度？
• 为了实现这场“性能革命”，defer 在编译器和运行时层面，经历了怎样一场从“堆分配”到“栈上开放编码(open-coded defer)”的“心脏手术”？

今天，就让我们再一次化身“Go 语言考古学家”，在Go issues以及Go团队那些著名的演讲资料中挖掘，并结合 Go 官方的设计文档，深入 defer 性能演进的“地心”，去完整地再现这场波澜壮阔的“救赎之路”。

“事后”的智慧：Defer 的设计哲学与独特性

在我们深入 defer 性能的“地心”之前，让我们先花点时间，站在一个更高的维度，欣赏一下 defer 这个语言构造本身的设计之美。defer机制 并非 Go 语言的首创，许多语言都有类似的机制来保证资源的确定性释放，但Go中defer 机制的实现方式却独树一帜，充满了 Go 语言独有的哲学。

保证“清理”的殊途同归

下面是几种主流语言的资源管理范式，这让我们能更清晰地看清 defer 的坐标：

• C++ 的 RAII (Resource Acquisition Is Initialization):

这是一种极其强大和高效的范式。资源（如文件句柄、锁）的生命周期与一个栈上对象的生命周期绑定。当对象离开作用域时，其析构函数 (destructor) 会被编译器自动调用，从而释放资源。RAII 的优点是静态可知、零运行时开销。但它强依赖于 C++ 的析构函数和对象生命周期管理，对于一门拥有垃圾回收（GC）的语言来说，这种模式难以复制。

• Java/Python 的 try-finally:

这是另一种常见的保证机制。finally 块中的代码，无论 try 块是正常结束还是抛出异常，都保证会被执行。try-finally 同样是静态可知的，编译器能明确地知道在每个代码块退出时需要执行什么。

这两种机制的共同点是：它们都是块级 (block-level) 的，并且清理逻辑的位置往往与资源获取的位置相距甚远。

Defer 的三大独特优势

相比之下，Go 的 defer 提供了三种独特的优势，使其在代码的可读性和灵活性上脱颖而出：

1. 就近原则，极致清晰 (Clarity):

这是 defer 最为人称道的优点。清理逻辑（defer f.Close()）可以紧跟在资源获取逻辑（os.Open(…)）之后。这种“开闭成对”的书写方式，极大地降低了程序员的心智负担，你再也不用在函数末尾的 finally 块和函数开头的资源申请之间来回跳转，从而有效避免了忘记释放资源的低级错误。

1. 函数级作用域，保证完整性 (Robustness):

defer 的执行时机与函数（而非代码块）的退出绑定。这意味着，无论函数有多少个 return 语句，无论它们分布在多么复杂的 if-else 分支中，所有已注册的 defer 调用都保证会在函数返回前被执行。这对于重构和维护极其友好——你可以随意增删 return 路径，而无需担心破坏资源清理的逻辑。更重要的是，在 panic 发生时，defer 依然会被执行，这为构建健壮的、能从异常中恢复的常驻服务提供了坚实的基础。

1. 动态与条件执行，极致灵活 (Flexibility):

这是 defer 与 RAII 和 try-finally 最本质的区别。defer 是一个完全动态的语句，它可以出现在 if 分支、甚至 for 循环中。

if useFile {
    f, err := os.Open("...")
    // ...
    defer f.Close() // 只在文件被打开时，才注册清理逻辑
}

这种条件式清理的能力，是其他静态机制难以优雅表达的。

“动态”的双刃剑

然而，defer 的动态性也是一把双刃剑。

正是因为它可以在循环中被调用，defer 在理论上可以被执行任意多次。编译器无法在编译期静态地知道一个函数到底会注册多少个 defer 调用。

这种不确定性，迫使 Go 的早期设计者必须借助运行时的帮助，通过一个动态的链表来管理 defer 调用栈。这就引出了我们即将要深入探讨的核心问题——为了这份极致的灵活性和清晰性，defer 在诞生之初，付出了怎样的性能代价？而 Go 团队又是如何通过一场载入史册的编译器革命，几乎将其“抹平”的？

现在，让我们带上“考古工具”，正式开始我们的性能探源之旅。

“原罪”：Go 1.13 之前的 defer 为何如此之慢？

在GopherCon 2020上，Google工程师Dan Scales为大家进行了一次经常的有关defer性能提升的演讲，在此次演讲中，他先为大家展示了一张令人震惊的性能对比图，也揭示了一个残酷的事实：在 Go 1.12 及更早的版本中，一次 defer 调用的开销高达 44 纳秒，而一次普通的函数调用仅需 1.7 纳秒，相差超过 25 倍！

这巨大的开销从何而来？答案隐藏在早期的实现机制中：一切 defer 都需要运行时（runtime）的深度参与，并且都涉及堆分配（heap allocation）。

让我们通过 Go 团队的内部视角，来还原一下当时 defer 的工作流程：

1. 创建 _defer 记录： 每当你的代码执行一个 defer 语句时，编译器会生成代码，在堆上分配一个 _defer 结构体。这个结构体就像一张“任务卡”，记录了要调用的函数指针、所有参数的拷贝，以及一个指向下一个 _defer 记录的指针。

1. deferproc 运行时调用： 创建好“任务卡”后，程序会调用运行时的 runtime.deferproc 函数。这个函数负责将这张新的“任务卡”挂载到当前 goroutine 的一个链表上。这个链表，我们称之为“defer 链”。

1. deferreturn 运行时调用： 当函数准备退出时（无论是正常 return 还是 panic），编译器会插入一个对 runtime.deferreturn 的调用。这个函数会像“工头”一样，从 defer 链的尾部开始（后进先出 LIFO），依次取出“任务卡”，并执行其中记录的函数调用。

看到了吗？每一次 defer，都至少包含：

• 一次堆内存分配（创建 _defer 记录）。
• 两次到运行时的函数调用 (deferproc 和 deferreturn)。

堆分配本身就是昂贵的操作，因为它需要加锁并与垃圾回收器（GC）打交道。而频繁地在用户代码和 runtime 之间切换，也带来了额外的开销。正是这“三座大山”，让 defer 在高性能场景下变得不堪重负。

Go 1.13 迈出了优化的第一步：对于不在循环中的 defer，编译器尝试将 _defer 记录分配在栈上。这避免了堆分配和 GC 的压力，使得 defer 的开销从 44ns 降低到了 32ns。这是一个显著的进步，但离“零成本”的目标还相去甚甚远。defer 依然需要与 runtime 交互，依然需要构建那个链表。

“革命”：Go 1.14 的 Open-Coded Defer

Go 1.14 带来的，不是改良，而是一场彻底的革命。Dan Scales 和他的同事们提出并实现了一个全新的机制，名为 “开放编码的 defer (Open-Coded Defer)”。

其核心思想是：对于那些简单的、非循环内的 defer，我们能不能彻底摆脱 runtime，让编译器直接在函数内生成所有清理逻辑？

答案是肯定的。这场“革命”分为两大战役：

战役一：在函数退出点直接生成代码

编译器不再生成对 deferproc 的调用。取而代之的是：

1. 栈上“专属”空间： 在函数的栈帧（stack frame）中，为每个 defer 调用的函数指针和参数预留“专属”的存储位置。
2. 位掩码（Bitmask）： 同样在栈上，引入一个 _deferBits 字节。它的每一个 bit 位对应一个 defer 语句。当一个 defer 被执行时，不再是创建 _defer 记录，而是简单地将 _deferBits 中对应的 bit 位置为 1。这是一个极快、极轻量的操作。

当函数准备退出时，编译器也不再调用 deferreturn。它会在每一个 return 语句前，插入一段“开放编码”的清理逻辑。这段逻辑就像一个智能的“清理机器人”，它会逆序检查 _deferBits 的每一位。如果 bit 位为 1，就从栈上的“专属空间”中取出函数指针和参数，直接发起调用：

看到了吗？在正常执行路径下，整个过程没有任何堆分配，没有任何 runtime 调用！defer 的成本，被降低到了几次内存写入（保存参数和设置 bit 位）和几次 if 判断。这使得其开销从 Go 1.13 的 32ns 骤降到了惊人的 3ns，与直接调用函数（1.7ns）的开销几乎在同一个数量级！

战役二：与 panic 流程的“深度整合”

你可能会问：既然没有 _defer 链表了，当 panic 发生时，runtime 怎么知道要执行哪些 defer 呢？

这正是 Open-Coded Defer 设计中最精妙、也最复杂的部分。Go 团队通过一种名为 funcdata 的机制，在编译后的二进制文件中，为每个使用了 Open-Coded Defer 的函数，都附上了一份“藏宝图”。

这份“藏宝图”告诉 runtime：

• 这个函数使用了开放编码。
• _deferBits 存储在栈帧的哪个偏移量上。
• 每个 defer 调用的函数指针和参数，分别存储在栈帧的哪些偏移量上。

当 panic 发生时，runtime 的 gopanic 函数会扫描 goroutine 的栈。当它发现一个带有 Open-Coded Defer 的栈帧时，它就会：

1. 读取这份“藏宝图” (funcdata)。
2. 根据“藏宝图”的指引，在栈帧中找到 _deferBits。
3. 根据 _deferBits 的值，再从栈帧中找到并执行所有已激活的 defer 调用。

这个设计，巧妙地将 defer 的信息编码在了栈帧和二进制文件中，使得 panic 流程依然能够正确地、逆序地执行所有 defer，同时保证了正常执行路径的极致性能。

下面是Dan Scales给出的一个defer性能对比结果：

我们看到：采用Open-coded defer进行优化后，defer的开销非常接近与普通的函数调用了(1.x倍)。

小结：“救赎”的完成与新的约定

defer 的性能“救赎之路”，从 Go 1.12 的 44ns，到 Go 1.13 的 32ns（栈分配 _defer 记录），再到 Go 1.14 的 3ns（Open-Coded Defer），其演进历程波澜壮阔，是 Go 团队追求极致性能与工程实用性的最佳例证。

下面是汇总后的各个Go版本的defer实现机制与开销数据：

这场“革命”之后，Dan Scales 在演讲的最后发出了强有力的呼吁，这也应该成为我们所有 Gopher 的新共识：

“defers should now be used whenever it makes sense to make code clearer and more maintainable. defer should definitely not be avoided for performance reasons.”
（现在，只要能让代码更清晰、更易于维护，就应该使用 defer。绝对不应该再因为性能原因而避免使用 defer。）

defer 的“原罪”已被救赎。从现在开始，请放心地使用它，去编写更优雅、更健壮的 Go 代码吧。

参考资料

• Proposal: Low-cost defers through inline code, and extra funcdata to manage the panic case – https://go.googlesource.com/proposal/+/master/design/34481-opencoded-defers.md
• GopherCon 2020: Implementing Faster Defers by Dan Scales – https://www.youtube.com/watch?v=DHVeUsrKcbM
• cmd/compile: allocate some defers in stack frames – https://github.com/golang/go/issues/6980

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

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

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

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

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

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

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

本文永久链接 – https://tonybai.com/2025/10/04/the-software-essays-that-shaped-me

大家好，我是Tony Bai。

二十年前，一位年轻的程序员在还未踏入职场时，便开始沉浸于软件开发的博客文章与深刻思考之中。二十年后，他已成为一名资深工程师，回首望去，成千上万的文字中，只有寥寥数篇真正沉淀下来，如基石般塑造了他的思维方式和职业生涯。

这份由 Michael Lynch 精心筛选出的“思想塑造清单”，本身就是一次对软件工程领域永恒智慧的巡礼。清单中的每一篇文章，都如同一个思想的火种，点燃了关于工程文化、代码哲学、乃至技术选型的深刻辩论。

今天，也让我们重新打开这些经典，逐一剖析其中的智慧，看看它们在瞬息万变的当下，能为我们——尤其是追求简约与高效的 Go 开发者——带来怎样历久弥新的启示。

1. Joel 测试：衡量开发者幸福感的 12 条黄金标准

(“The Joel Test: 12 Steps to Better Code” by Joel Spolsky, 2000)

Joel Spolsky 的这 12 个问题，与其说是对代码质量的测试，不如说是一面镜子，映照出一家公司是否真正尊重开发者的时间和心智。二十多年过去了，这些问题依然是衡量一个工程团队成熟度的“试金石”。

1. Do you use source control? (你用源码控制吗？)
2. Can you make a build in one step? (你能一步构建吗？)
3. Do you make daily builds? (你每天都构建吗？)
4. Do you have a bug database? (你有 Bug 数据库吗？)
5. Do you fix bugs before writing new code? (你先修 Bug 再写新代码吗？)
6. Do you have an up-to-date schedule? (你有最新的排期吗？)
7. Do you have a spec? (你有需求规格说明吗？)
8. Do programmers have quiet working conditions? (程序员有安静的工作环境吗？)
9. Do you use the best tools money can buy? (你用钱能买到的最好工具吗？)
10. Do you have testers? (你有测试人员吗？)
11. Do new candidates write code during their interview? (新候选人在面试时会写代码吗？)
12. Do you do hallway usability testing? (你做“走廊可用性测试”吗？)

虽然“每日构建”在今天已被“持续集成”(CI) 所取代，“Bug 数据库”也演变成了 Jira 或 Linear，但其精神内核——减少摩擦、自动化、系统化地管理混乱——从未过时。对于 Go 开发者而言，go build 的一步构建、go test 的内置测试、以及强大的静态分析工具链，都是对“Joel 测试”精神的现代回应。当你评估一个团队或项目时，不妨在心中过一遍这 12 个问题，它的得分，往往比任何花哨的技术栈更能说明问题。

2. 解析，而非验证：用类型系统构建“安全默认”的代码

(“Parse, don’t validate” by Alexis King, 2019)

这篇文章的核心论点，对于任何一个使用静态类型语言（如 Go）的开发者来说，都具有革命性的意义：“每当你验证一段数据时，你应该将它转换成一个新的类型。”

传统（脆弱的）做法：

// 每次使用前，都得记得调用它
func validateUsername(username string) error { ... }

这种做法的问题在于，它将验证的责任推给了开发者。你必须在代码的每一个角落，都记得去调用 validateUsername，一旦遗漏，就可能导致安全漏洞或数据损坏。

“解析，而非验证”的哲学：

// 定义一个全新的、无法被随意创建的类型
type Username string

// 唯一的入口：一个“解析”函数，它在内部执行验证
func ParseUsername(raw string) (Username, error) {
    if err := validate(raw); err != nil {
        return "", err
    }
    return Username(raw), nil
}

// 后续的业务逻辑，只接受这个被“祝福”过的类型
func GreetUser(u Username) { ... }

这种模式利用类型系统，将安全检查从一种“需要开发者时刻牢记的纪律”，转变为一种“由编译器强制执行的保证”。一旦你有了一个 Username 类型的变量，你就拥有了一个不可辩驳的证明——它必然是合法的。这在 Go 中极易实现，通过创建新的具名类型，我们可以轻松地在代码中构建起一道道安全的“防火墙”，让非法状态根本没有机会存在。

3. 无银弹：正视软件开发的“本质复杂性”

(“No Silver Bullet” by Fred Brooks, 1986)

这篇来自《人月神话》作者的经典文章，将软件开发工作划分为两个核心部分：

• 本质复杂性 (Essential Complexity)：与问题领域本身固有的、不可简化的复杂逻辑作斗争。例如，设计一套复杂的保险计价公式。
• 偶然复杂性 (Accidental Complexity)：与工具、环境和实现细节作斗争。例如，处理内存泄漏、等待编译、配置构建系统。

Brooks 的核心论点是：过去几十年软件开发效率的巨大提升，主要来自于对“偶然复杂性”的削减。但无论工具如何发展，我们永远无法消除“本质复杂性”。因此，不存在任何能够带来数量级生产力提升的“银弹”。

这篇文章是对抗技术领域“炒作周期”的最佳解毒剂。无论是微服务、Serverless、还是当下的 AI，它们在很大程度上解决的都是“偶然复杂性”。Go 语言的诞生，其核心目标——极快的编译速度、简单的并发模型、自动的垃圾回收——本身就是对 C++ 等语言“偶然复杂性”的一次宣战。

Brooks 的理论让我们保持清醒：即使 AI 能为我们编写代码，但定义需求、设计系统、测试复杂交互这些“本质复杂性”的工作，依然是人类工程师不可替代的价值所在。

4. 选择的代价：为用户做明智的决定

(“Choices” by Joel Spolsky, 2000)

Joel Spolsky 敏锐地指出：“你每提供一个选项，就是在要求用户做一次决策。” 过多的选择，尤其是那些用户并不具备足够信息来做出的选择，会中断用户的心流，带来挫败感。

他以 Windows 98 中一个荒谬的帮助搜索设置为例，痛斥了将底层技术决策（如“最小化数据库大小”或“最大化搜索能力”）推给普通用户的设计懒政。

这个原则不仅适用于 GUI，更适用于我们编写的任何 API 和命令行工具。当你的函数需要一大堆配置参数时，问问自己：

• 这些选项真的都是必需的吗？
• 我是否可以根据大多数场景，提供一个明智的、开箱即用的默认行为？
• 对于必须暴露的选项，我能否通过 Go 的选项模式 (Options Pattern) 来组织它们，让简单的使用保持简单，让复杂的配置成为可能？

一个优秀的 API 设计者，应该是一个“仁慈的独裁者”，敢于为用户承担决策的责任，只在真正必要时，才将选择的权力交还给他们。

5. 兼容性是为用户，而非为程序

(“Application compatibility layers are there for the customer, not for the program” by Raymond Chen, 2010)

Raymond Chen 用一个尖刻的比喻，讽刺了那些期望操作系统为他们的旧软件提供无限向后兼容性的开发者。然而，文章作者 Michael Lynch 反思后认为，这个比喻的背后，其实蕴含着一个更深刻的用户行为洞察：用户永远会选择阻力最小的路径。

如果你发现用户在以一种“错误”但“有效”的方式使用你的系统（比如，依赖一个 Bug 来实现某个功能），那么你的责任不是嘲笑他们，而是去理解他们为何这么做，并提供一条更简单、更正确的路径来引导他们。

这条规则对我们如今进行API设计也是大有借鉴意义的，这意味着我们需要时刻保持同理心。如果你发布了一个有 Bug 的 v1 版本，并且发现大量用户已经围绕这个 Bug 构建了他们的系统，那么在 v2 版本中，简单地“修复”这个 Bug 可能会导致大规模的破坏。

一个更负责任的做法可能是：

1. 在 v2 中提供一个新的、行为正确的 API。
2. 保留 v1 的旧 API，但将其标记为废弃，并在文档中清晰地解释其错误行为和迁移路径。
3. （在 Go 1.26+ 中）甚至可以利用 //go:fix 指令，为用户提供自动化的迁移工具。

6. 不要在测试中引入逻辑

(“Don’t Put Logic in Tests” by Erik Kuefler, 2014)

我们通常被教导要在生产代码中遵循 DRY (Don’t Repeat Yourself) 原则。但 Erik Kuefler 指出，将这一原则盲目地应用到测试代码中，可能是一场灾难。

糟糕的测试：

// 为了“ DRY ”，我们拼接了 URL
assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl());

这段代码隐藏了一个微小的 Bug（多了一个斜杠），因为它需要读者在脑中进行一次字符串拼接运算才能发现问题。

优秀的测试：

// 清晰、直白，一眼就能看出期望的结果
assertEquals("http://plus.google.com//u/0/photos", nav.getCurrentUrl());

虽然存在字符串冗余，但它的意图是一目了然的。

测试代码的首要目标是清晰性，而非优雅或无冗余。测试代码没有它自己的测试，验证其正确性的唯一方式就是人工审查。因此，一段好的测试，应该像一篇优秀的规格说明文档，让任何一个读者都能毫不费力地理解它在断言什么。在 Go 的表驱动测试 (Table-Driven Tests) 中，这一点体现得尤为重要：绝大多数情况下，输入和期望的输出应该被清晰地、并排地列出，而不是通过复杂的辅助函数动态生成。

7. 一点原生 JavaScript 就能做很多事

(“A little bit of plain Javascript can do a lot” by Julia Evans, 2020)

Julia Evans 曾分享了她从一个坚定的“前端框架拥护者”转变为“原生 JavaScript 爱好者”的心路历程。在饱受了 Angular, React, Vue 等框架带来的依赖问题和复杂性的折磨后，她决定尝试只用原生 JavaScript（现代的 ES2018 标准）来构建一个 Web 界面。

结果令她震惊：没有框架、没有构建步骤、没有 Node.js，她依然能完成 90% 的工作，而开发体验的“头痛程度”只有 5%。当出现运行时错误时，她看到的不再是经过压缩、转换的“天书”，而是她自己写的、清晰可辨的代码。

这篇文章是对现代软件开发中“框架至上”文化的一次有力反思。它提醒我们，在引入任何一个大型框架或库之前，都应该先问自己：我真的需要这个吗？标准库或语言本身的能力是否已经足够？

对于 Go 开发者而言，这种思想更是与语言的哲学不谋而合。Go 拥有一个极其强大的标准库（特别是 net/http），在许多场景下，你完全不需要引入像 Gin 或 Echo 这样的 Web 框架，就能构建出高性能、可维护的 Web 服务。

Julia 的经历鼓励我们，要敢于挑战对框架的“路径依赖”，重新审视并信任我们手中工具（无论是 JavaScript 还是 Go 标准库）的内建能力。有时候，最简单的解决方案，恰恰就在我们眼前。

8. 选择无聊的技术

(“Choose Boring Technology” by Dan McKinley, 2015)

这篇经典文章的标题本身，就是其全部智慧的浓缩。Dan McKinley 警告我们，在启动一个新项目时，要警惕那些闪亮、前沿、充满炒作的新技术的诱惑。

• 新技术：有未知的 Bug 和弱点，当你遇到问题时，社区可能还没有解决方案，你将孤立无援。
• “无聊”的技术（如 Postgres, Java, Go）：虽然有其自身的问题，但经过数十年（或多年）的实战检验，它们几乎所有可能遇到的问题，都有成熟的、有据可查的解决方案。

McKinley 提出了一个有趣的模型：每个公司都有三枚“创新代币” (innovation tokens)。如果你想在一个项目中使用一项未经充分验证的新技术，你就必须花掉一枚代币。请明智地使用它们。

Go 语言本身，在许多方面，已经成为了“无聊技术”的典范。它稳定、向后兼容、拥有强大的标准库和成熟的生态。当我们进行技术选型时，应该问自己：我们当前的核心问题，真的需要一个全新的、我们团队不熟悉的“闪亮新事物”来解决吗？还是说，用我们已经精通的“无聊”工具，就足以应对挑战？选择“无聊”，往往是通往项目成功最可靠的路径。

9. 我把自己锁在了数字生活之外

(“I’ve locked myself out of my digital life” by Terence Eden, 2022)

这篇文章以一个引人入胜的思想实验开场：如果一道闪电击中了你的房子，摧毁了你所有的电子设备，你将如何恢复你的数字生活？

作者 Terence Eden 意识到，尽管他有密码管理器、硬件密钥和多重备份，但所有这些安全措施的“入口”，都依赖于他手边的某个设备。如果所有设备同时被毁，他将无法访问密码管理器，也无法使用硬件密钥，从而陷入一个无法恢复的死循环。

这个故事迫使读者思考一个被我们常常忽略的问题：我们的灾难恢复计划，是否本身就依赖于那些可能会在灾难中一同消失的东西？

这篇文章的教训，超越了个人数字安全，直指系统设计的核心——韧性 (Resilience) 和 避免单点故障。

当我们设计一个分布式系统时，我们是否考虑过最坏的情况？

• 我们的备份恢复流程，是否依赖于某个中心化的、可能会一同宕机的认证服务？
• 我们的配置中心如果不可用，应用是否能以一种“降级”但仍可用的模式启动？
• 在多云或混合云部署中，我们的跨区域故障转移方案，是否隐藏了对某个单一 DNS 提供商或证书颁发机构的隐式依赖？

Terence 的故事提醒我们，真正的系统韧性，不仅仅是拥有备份和冗余，更是要反复审视和测试我们的恢复路径，确保在极端情况下，我们不会发现自己“被锁在门外”。

10. Bonus：Brad Fitzpatrick 论输入验证的“咆哮”

(Brad Fitzpatrick on parsing user input, 2009)

最后，是一段来自 Go 社区大神、Memcached 和 LiveJournal 的创造者 Brad Fitzpatrick 的“咆哮”，这段话源于一本访谈录《Coders at Work》。当被问及软件工程的伦理时，他将矛头直指糟糕的输入验证：

“我希望每个人在他们的信用卡表单上都能保持一致，让我TMD能输入空格或连字符。计算机很擅长移除那些狗屎。别告诉我该如何格式化我的数字。”

这段充满激情的“粗口”，完美地概括了一个核心的用户体验原则：宽进严出 (Be liberal in what you accept, be conservative in what you produce)。

作为 API 或 UI 的设计者，我们的责任是尽可能地减轻用户的负担。计算机是用来处理繁琐、重复性工作的。如果用户输入了一个带空格的电话号码，或者一个全角的逗号，我们的程序应该默默地、智能地将其清理和格式化，而不是粗暴地拒绝并抛出一个错误。

Fitzpatrick 的“咆哮”时刻提醒着我们：每一次当你设计一个输入字段时，都要站在用户的角度思考，并记住那句话——“计算机很擅长移除那些狗屎。”

小结：构建衡量“好”与“坏”的永恒坐标系

从 Joel Spolsky 对工程文化的拷问，到 Fred Brooks 对复杂性的深刻剖析；从 Alexis King 对类型安全的精妙论证，到 Dan McKinley 对技术选型的务实忠告…… 当我们跟随 Michael Lynch 的脚步，完成这次跨越四十年的思想巡礼后，我们收获的远不止是一份“书单”。

技术浪潮来了又去，今天我们手中的工具，明天可能就会过时。但这些围绕着“人”的根本原则——清晰性、简单性、健壮性、同理心、风险意识——却是永恒的。它们是区分一名普通的“代码实现者”与一位真正的“软件工程师”的分水岭。

这份清单，最终为我们构建的，是一个内心深处的、用以衡量“好”与“坏”的永恒坐标系。在未来的职业生涯中，无论面对何种炫目的新技术或棘手的工程问题，这个坐标系都将指引我们，做出更明智、更持久、也更具价值的决策。

资料链接：https://refactoringenglish.com/blog/software-essays-that-shaped-me

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

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

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

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

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

想系统学习Go，构建扎实的知识体系？

我的新书《Go语言第一课》是你的首选。源自2.4万人好评的极客时间专栏，内容全面升级，同步至Go 1.24。首发期有专属五折优惠，不到40元即可入手，扫码即可拥有这本300页的Go语言入门宝典，即刻开启你的Go语言高效学习之旅！

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