本文永久链接 – https://tonybai.com/2025/10/15/physics-in-fanren

大家好，我是Tony Bai。

李淼教授的《三体中的物理学》曾让我们惊叹，原来恢弘的科幻背后，是坚实而又前沿的科学基石。读完《凡人修仙传》人界/灵界篇后，一个念头在我脑海中挥之不去：我们能否为韩立的修仙世界，构建一个自洽的“物理模型”？

这并非要用科学去“祛魅”修仙，恰恰相反，这是一场思想实验。我们旨在探讨：如果修仙世界真的存在，其背后的“天道法则”是否能在现代物理学的框架内找到惊人相似的“投影”？

当韩天尊遇见爱因斯坦，一场连接东方玄幻与前沿科学的奇妙对话，就此展开。我们不纠结“灵气”的具体成分，而是聚焦于修仙世界中更高阶的时空、维度与法则。

界面飞升 —— 膜宇宙理论与高维空间

在《凡人》中，世界由无数“界面”构成——人界、灵界、小灵界、灵寰界、仙界……界面之间壁垒森严，修士需经历九死一生的“飞升”才能跨越。更奇特的是，不同界面的“天地法则”也不同，灵界的空间远比人界稳固，能承受的能量上限也更高。

这听起来玄之又玄，但在现代物理学的前沿，却有一个理论与之惊人地契合——膜宇宙理论（Brane Cosmology）。

源于弦理论/M理论的“膜宇宙”模型认为，我们熟悉的三维宇宙（长宽高），可能只是一张漂浮在更高维度“体宇宙”（The Bulk）中的巨大“膜”（Brane）。想象一下，无数张平行的纸（膜宇宙）漂浮在一个巨大的房间（体宇宙）里。

现在，让我们进行一次大胆的映射：

1. 界面 = 膜宇宙 (Brane)： 每个人界、灵界，都是一个独立的“膜宇宙”。它们在更高维度中彼此平行，互不干涉。
2. 飞升 = 跨膜运动 (Brane-hopping)： 什么是飞升？它不是在我们的三维空间里向上飞。而是修士集聚了无法想象的能量，将自己从当前所在的三维“膜”上撕裂出去，进入高维的“体宇宙”，再“降落”到另一个物理常数不同的“膜”上。这完美解释了飞升为何如此艰难，因为“体宇宙”中可能充满了凡人无法理解的能量风暴。
3. 法则不同 = 物理常数差异： 为何灵界空间更稳固？因为不同“膜”上的物理常数、真空能级可能完全不同。灵界那张“膜”的“时空曲率韧性”远超人界，因此能承载更恐怖的能量冲击。

从这个角度看，韩立的飞升，本质上是一次壮丽的高维时空迁跃。

空间裂缝与传送阵 —— 爱因斯坦-罗森桥（虫洞）

在凡人世界，长距离旅行依赖两种方式：稳定精确的传送阵，和天然但危险的空间裂缝。这两种设定，直指广义相对论中一个最迷人的预言——虫洞（Wormhole）。

虫洞，又称爱因斯坦-罗森桥，是理论上连接时空遥远两点的“捷径”。它不是在空间中移动，而是通过更高维度直接“抄近路”。

现在，让我们重新审视韩立的旅行方式：

1. 传送阵 = 人造稳定虫洞： 古代大能修士建造的传送阵，其复杂的符文和灵石能量系统，本质上是一套用于打开并维持一个微型、稳定虫洞的“物理装置”。所谓的“空间节点”，就是时空几何上最适合用当前技术打开虫洞的坐标。驱动传送阵需要海量灵石，这或许就是维持虫洞“喉咙”张开所需的庞大能量。
2. 空间裂缝 = 天然不稳定虫洞： 自然形成的空间裂缝，由于缺乏稳定机制，极其危险，随时可能坍塌。这与物理学中对天然虫洞的描述不谋而合——它们可能瞬息万变，任何物质穿过都可能被潮汐力撕碎。
3. 空间神通 = 局部时空扭曲： 大乘期修士的“瞬移”，可以理解为他们凭借强大的神识和法力，能够小范围、短时间地剧烈扭曲时空几何，制造出临时的、仅供自己通过的微型虫洞。

所以，韩立每一次踏上传送阵，都可能是一次穿越时空隧道的星际旅行。

御风遁光 —— 引力操控与质能转换

除了跨越星辰大海的传送，修士最常用的神通莫过于“遁术”。从御风而行，到脚踏法器，再到化为一道惊天长虹，其背后可能隐藏着对宇宙基本力之一——引力——的精妙操控。

我们都知道，引力的本质是质量导致的时空弯曲。那修士是如何摆脱这无处不在的束缚，实现自由飞行的呢？

1. 御器飞行 = 局部反重力场： 筑基期修士脚踏法器飞行，并非是站在一个“会飞的盘子”上那么简单。一个更令人信服的物理学解释是：修士通过法力（能量）作用于法器，在法器周围制造了一个小范围的、方向可控的“反引力场”或“时空斥力泡”。这个斥力泡抵消了星球的引力，通过改变场的方向和强度，就能实现远超空气动力学的超高速机动。这需要对广义相对论有极深的理解，或是掌握了能产生“负能量密度”的奇特物质。

2. 化虹遁光 = 质能转换（E=mc²）： 元婴期后的高阶遁术，修士自身化为一道光，这已经超越了反重力的范畴。这极有可能触及了爱因斯坦质能方程的终极应用。高阶修士通过某种秘法，能将自身部分静止质量/法力暂时转化为纯粹的能量形态（类似光子流）。在这种状态下，他们以接近光速行进，自然呈现为“遁光”。到达目的地后，再将能量逆转为物质，重新凝聚成形。

境界越高，飞得越快，也得到了合理解释：要么是输出功率更大，反引力场更强；要么是对法则理解更深，质能转换的效率更高、损耗更小。

时间法则 —— 相对论、熵增与时间箭头

《凡人》中，时间法则是至高无上的仙界三大至尊法则之一。韩立的掌天瓶和《真言化轮经》能操控时间流速，甚至进行有限的时间回溯。这触及了物理学最核心的领域。

1. 时间加速/延缓 = 极端时空曲率： 根据爱因斯坦的广义相对论，强大的引力场可以使时间变慢（引力时间膨胀）。掌天瓶内的神秘空间，或许就是通过某种机制，制造出一个超乎想象的等效引力场，从而让内部的时间流速相对于外界急剧变慢（即外界看来是“加速”了植物生长）。而《真言化轮经》的“时间延缓”，则可能是在敌人周围制造了类似的强时空曲率。

2. 逆转时间 = 逆转熵增： 这是最挑战物理学根基的能力。我们的宇宙之所以有明确的时间方向（时间之矢），根源在于热力学第二定律——孤立系统的“熵”（混乱度）总是趋向于增加。一杯热水会变凉，但一杯凉水不会自己变热。能够局部逆转时间，意味着能够在该区域内逆转熵增定律，让破碎的镜子复原，让死去的人复活。这需要对物质和能量进行完美的信息重组，其难度和能量级别是宇宙级的。这也解释了为何此法则是最顶级的力量，连道祖都难以完全掌控。

韩立每一次催动掌天瓶，都是在自己的掌中，上演着一场微缩版的《星际穿越》。

真幻之境 —— Matrix、拟像理论与缸中之脑

除了扭曲时空，修仙世界还有一种令人不寒而栗的力量——幻阵。尤其是仙界篇中冥寒仙宫那个足以以假乱真的“大千世界幻阵”，它并非简单的视觉欺骗，而是一个拥有独立法则和亿万生灵的“真实世界”。

这让我们立刻联想到了另一部伟大的作品——《黑客帝国》（The Matrix）。

1. 顶级幻阵 = 私有化Matrix服务器： 影片中，人类活在由机器构建的虚拟世界“母体”中。而冥寒仙宫的幻阵，本质上就是一个由布阵道祖创建并维护的“私有化Matrix”。它绕过了修士的肉体感官，直接作用于其“元神”或“神识”（可以理解为意识的量子信息态），向其输入一个完整、自洽、毫无破绽的虚拟世界信息流。

2. 神识 = 算力与防火墙： 为何韩立能凭借强大的神识勘破幻阵？在这里，“神识”可以被理解为修士意识的“个人算力”与“网络防火墙”。强大的神识能够实时分析海量信息流，检测到其中的微小不一致（Bug或逻辑漏洞），或者能强行抵御外部信号的入侵，从而大喝一声：“原来是幻术！”并强制“下线”。

3. 大千世界幻阵 = 真实副本（Digital Twin）： 这个幻阵之所以恐怖，因为它可能不是凭空捏造，而是布阵者对某个真实世界进行了完美的1:1信息复制，创造了一个“数字孪生”世界。在这个副本中，万事万物都遵循与原型世界完全一致的“物理法则”（算法），因此身处其中的生灵，哪怕穷尽一生也无法发现破绽。

这最终引向了那个古老的哲学思辨——“缸中之脑”。如果一个幻境完美到你永远无法证明它是假的，那么这个“幻境”与“真实”，究竟还有区别吗？韩立在幻阵中的挣扎，其实也是我们很多个人在看完《黑客帝国》这部电影后，对自身存在真实性的终极追问。

灵光护体与禁制 —— 力场护盾及可编程物质

从宏大的时空理论回到激烈的战斗场景，修士的“护体灵光”和无处不在的“禁制”，同样能在未来科技的蓝图中找到令人兴奋的对应——那就是科幻迷们心心念念的力场护盾（Force Field）与可编程物质（Programmable Matter）。

1. 护体灵光 = 个人化力场护盾： 当修士面对攻击时，体表会瞬间浮现一层流光溢彩的能量罩。这并非某种魔法，而极有可能是一个由修士自身能量（灵力）维持的个人化力场护盾。正如《星际迷航》中的企业号能张开防御屏，修士通过功法，将灵力转化为特定的能量形态（如强磁场约束的等离子体），在体表形成一个动态屏障，用以偏转或吸收来袭的攻击。功法不同，护盾属性各异，这与力场护盾可以调整频率以应对不同类型攻击的设定如出一辙。

2. 禁制 = 宏观尺度的可编程物质： 守护洞府的强大禁制，由亿万个微小符文构成，这与“可编程物质”的概念简直是天作之合。想象一下，每一个闪烁的“符文”，就是一个能量态的“智能元胞”。布阵者通过神识，为这亿万个元胞预先设定好了响应逻辑（程序）。一旦有外敌入侵，这些元胞便会根据预设程序瞬间重组，形成锋利的刀剑、坚固的壁垒或是困人心神的迷雾。

破禁之道：破解与过载打击

面对如此复杂的系统，修士们通常有两条路可走：

• 以巧破禁： 精通阵法者，会像顶尖黑客一样，仔细研究禁制（分布式系统）的符文结构（代码逻辑），寻找其薄弱环节或逻辑漏洞，然后用极小的代价将其瘫痪或绕过。这需要极高的“技术水平”（阵法造诣）。

• 蛮力破禁： 这更为常见，也更为直接。它不再寻求破解，而是进行一场纯粹的能量对撞，如同用压倒性的DDoS（分布式拒绝服务）攻击去冲击一台服务器。禁制系统的维持和响应都需要消耗能量。蛮力破禁就是用远超其能量储备或能量疏导效率上限的攻击，持续不断地轰击。当禁制的能量核心（灵石或阵眼）被耗尽，或者其符文结构因无法承受如此巨大的能量冲击而崩溃时，禁制自然告破。

这也就解释了为何高阶修士面对低阶禁制，往往一击即溃。因为双方的能量输出功率（Power Output）根本不在一个数量级上。

小结：殊途同归的求索

回顾我们这场横跨仙侠与科学的思想漫游，旅程是如此的波澜壮阔：从修士最基本的御风飞行（引力操控），到守护自身的能量力场（护体灵光）；从跨越星海的界面飞升（膜宇宙），到折叠空间的传送虫洞（传送阵）；从操控时间流速的至高法则，到构建虚拟实相的骇客帝国（幻阵）…… 我们发现，《凡人修仙传》中那些最天马行空的设定，竟能在现代物理学以及信息学的前沿理论中找到如此多的共鸣。

这并非巧合，而是因为无论是东方玄幻的“参悟天道”，还是现代科学的“探索规律”，其本质都是智慧生命试图理解宇宙运行的根本法则、并最终掌握自身命运的渴望。

韩立内视己身，神游太虚，追寻的是大道的本源；科学家仰望星空，对撞粒子，探索的是宇宙的真理。或许，他们看到的，是同一座山峰在不同方向的倒影。

也许在宇宙的某个角落，真的存在着一个可以用“灵力”来撬动物理法则的文明。对于宇宙而言，魔法和科学，或许只是对同一套规则的不同解读方式罢了。

参考资料

• 《三体中的物理学》- https://book.douban.com/subject/33435186/
• 膜宇宙理论 – https://arxiv.org/abs/hep-th/0209261
• 虫洞 – https://simple.wikipedia.org/wiki/Wormhole

你的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/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语言高效学习之旅！

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