本文永久链接 – 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/12/the-programmer-identity-crisis

大家好，我是Tony Bai。

“我是一个程序员。一个编码者。一个键盘牛仔……这是我的乐趣，也是我的身份认同。”

近日，一篇题为《程序员的身份危机》的博文在技术社区中引发了广泛的共鸣与讨论。作者Simon Højberg以一个“手艺人”的深情独白开篇，将我们带回了编程的黄金时代——那个在 MIT 26 号楼里，伴随着早期晶体管蜂鸣声，黑客们为了追求“The Right Thing”（那个完美的、简洁优雅的程序）而沉浸于机器语言的“黑暗艺术”的年代。

然而，作者笔锋一转，指出现代 AI 浪潮正以前所未有的力量，威胁着这份传承了近 70 年的技艺（Craft）和身份认同。曾经那个充满奇迹、成就感和优雅解谜的编程未来，如今正被一层“不祥的黑暗、骗局和不确定性”所笼罩。这是一篇警示性的檄文，它迫使我们每一个技术从业者去思考一个根本性问题：当 AI 接管了“思考”，我们还剩下什么？

“规范工程师”的崛起与“技艺”的消逝

文章尖锐地指出，如果我们相信 AI 行业的亿万富翁、Hacker News 的舆论领袖和 LinkedIn 上的 LLM 狂人，那么软件开发的未来将与“编程”本身几乎毫无关系。一种被称为 “Vibe Coding(氛围编程)” 的新模式正在成为主流。

在这个新世界里，我们的角色被重新定义为 “规范工程师 (Specification Engineering)”：

• 输入从代码到 Markdown： 我们不再是深入代码库、解决复杂谜题、发掘技术秘密的工匠，而是变成了在 Markdown 中编写规范的“需求者”。
• 思考过程外包： 创造性的解谜过程被全权交给了机器，我们只需在多个 AI Agent 的标签页之间进行上下文切换，拥抱一种“分散的认知”。我们从创作者，沦为了“与其技艺相分离的操作员”。

作者悲观地认为，这种转变是对程序员独特抽象思维能力的贬低，将我们推向了一个本已由产品经理和设计师占据的领域。更令人不安的是，一些开发者似乎欣然接受了这个新身份，乐于扮演“指挥管弦乐队”的史蒂夫·乔布斯，却忘记了编程的乐趣源于成为那个亲手打造乐器的沃兹尼亚克。

当工具选择权被剥夺：来自管理的“新叙事”

这场身份危机不仅是技术演进的自然结果，更在企业内部被一股力量所推动。

文章观察到，在“疯狂追求生产力”的竞赛中，企业的管理者们正以一种前所未有的方式，强制要求开发者使用特定的 LLM 工具——“要么遵从，要么出局”。这在历史上是罕见的。我们的工具，无论是 Vim、Emacs 还是 VS Code，都如同厨师的刀、木匠的刨，是我们精心配置、用以匹配自己思维模式的“圣殿”。而如今，这种个性化的选择权正在被自上而下地剥夺。

作者认为，这种管理层叙事的转变，为他们提供了一种“打破过去几十年来程序员在公司中备受优待的平衡”的新方式。

对“自然语言编程”的古老警告

一些人将 LLM 的兴起，类比于从汇编到 Fortran 的语言革命。作者强烈反对这种类比，他认为两者有本质区别：

1. Fortran 根植于编程： 它没有消除编程的形式化，而是扩展了其表达力和精度。
2. Fortran 是可预测的： 给定输入，它总能产生正确的结果。

而 LLM 及其所依赖的自然语言指令，其本质是不精确的。这与程序员所珍视的一切背道而驰：可预测性、组合性、幂等性，以及那些不会“摇摆不定”的集成测试。 LLM 生成的代码代表了这一切的反面：不一致的混乱。

文章引用了计算机科学先驱迪杰斯特拉 (Dijkstra) 对“自然语言编程的愚蠢”的深刻批判：

“形式化文本的美德在于，它们的操纵只需要满足少数简单的规则即可……当你思考它时，你会发现，当我们使用母语时，我们几乎不可能避免各种各样的无稽之谈，而形式化文本是一个惊人有效的工具，可以排除所有这些胡说八道。”

我们对计算机精度的依赖和信任，或许正是我们如此轻易相信聊天机器人“言之凿凿”的原因，即使它们正在“煤气灯”般地误导我们。

注：“煤气灯效应”（Gaslighting）是一种心理操控手段，施加者通过不断地否认事实、扭曲真相，使受害者质疑自己的记忆、感受和理智。

认知外包的代价：丧失“理论构建”的能力

作者坦言，他发现自己在审查 LLM 生成的代码时，远不如审查自己或同事编写的代码时那么仔细。LLM 生成的代码似乎有一种天生的魔力，让人的“眼睛变得呆滞”。我们草草浏览，盲目接受，只要 CI 通过、程序能够编译，便万事大吉。直到几个小时后，才发现自己工作的基石早已腐烂。

这种“认知外包”的代价是巨大的。它剥夺了我们与代码库深度连接的机会，剥夺了我们形成对领域、问题和解决方案深刻理解的过程。

文章引用了 Peter Naur 的经典著作《编程即理论构建 (Programming as Theory Building)》。Naur 认为，编程的主要产出不是软件本身，而是程序员脑中构建起的关于代码库的“理论”——关于它如何运作、其形式化表达以及与现实世界的映射。只有具备了这个完善的“理论”，我们才能有效地对其进行扩展和修复。

而“Vibe-Coding”那种对 AI 生成代码的“矛盾一瞥”，使得构建这种理论变得极其困难，甚至不可能。优秀的设计源于沉浸，源于在文本缓冲区中反复推敲，甚至源于离开键盘的深度思考。AI 带来的“无摩擦”工作流，恰恰让我们避开了那些本可以通过迭代和探索“丑陋方案”才能最终发现优雅设计的道路。

小结：我愿为一名手艺人，而非操作员

文章最后，作者发出了充满个人情感的呐喊。他承认，让 AI 处理重复性的样板代码、或在文档海洋中寻找答案，并非坏事。但他“极度不愿”仅仅成为一个操作员或代码审查者，将有趣和创造性的工作拱手让人。

“我想要驾驶，想要沉浸于技艺，想要在管弦乐队中演奏，想要解决复杂的谜题。我愿为一名程序员，一名手艺人。”

作者认为，即使 LLM 达到了宣传中的高度，我们仍将失去我们之所以成为我们的根本：我们的技艺、我们的乐趣、我们与同事的连接，以及我们对所创造软件的自主理解。

这篇文章并非全然否定 AI，而是在 AI 狂热的叙事中，为“编程”这门古老而精妙的技艺发出了一声响亮且充满尊严的捍卫。它提醒我们，工具的进步不应以抹杀思考为代价，就像技术的进步不应以剥夺人们的工作和生存权利为代价一样。作为工程师，最终提供的价值在于我们的批判性思维、解决问题的乐趣以及我们亲手打磨的技艺。这些，或许才是 AI 时代下我们真正的“护城河”。

资料链接：https://hojberg.xyz/the-programmer-identity-crisis/

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

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

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

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

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

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

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

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