第 6 章函数、延迟与恐慌 on Go 语言原本

6.1 函数调用

Mon, 01 Jan 0001 00:00:00 +0000

6.1 函数调用

函数是 Go 的一等公民，可以赋值、传递、返回、捕获外部变量成为闭包。这背后是两件事的实现：函数值（闭包）在内存里如何表示，以及一次函数调用在底层如何传参与返回。后者还藏着 Go 1.17 一次悄无声息却影响全局的变革：从栈传参改为寄存器传参。这一节把这两件事讲透，并在它们的接缝处点出一个关键事实，正是这个事实把「闭包是什么」与「调用怎么发生」焊成同一件事。

6.1.1 函数值与闭包

一个 func 类型的值，本质是一个指向闭包对象的指针。运行时给这个对象起的名字是 funcval，它在 runtime/runtime2.go 里的定义短得出奇：

1
2
3
4
5


// funcval：函数值在运行时的表示（来自 runtime2.go，已加注释）
type funcval struct {
 fn uintptr
 // 后面紧跟变长的、与具体函数相关的数据，即被捕获的环境
}

只有一个固定字段 fn,函数代码的入口地址。注释里那句「variable-size, fn-specific data here」才是闭包的灵魂：紧随 fn 之后，编译器排布着这个闭包捕获的外部变量。一个不捕获任何变量的普通函数，它的 funcval 只有 fn 一字，全局唯一、只读；一旦它捕获了外部变量，编译器就要为每次求值在堆上构造一个带捕获数据的 funcval。可以把它画成这样：

flowchart LR
 FV["func 值<br/>（一个指针）"] --> CO
 subgraph CO["闭包对象 funcval"]
 direction TB
 FN["fn：函数代码入口地址"]
 CAP["captured：被捕获的变量<br/>（如 &x, &y，按引用）"]
 FN --- CAP
 end
 CALL["调用 f()"] -.->|取 fn 字段间接跳转| FN

调用一个函数值，就是取出 fn 字段间接跳转过去，与接口的方法分发（4.2）异曲同工。关键细节是捕获按引用：闭包捕获的是变量本身，不是它当时的值。下面这段代码里，counter 返回的两个闭包共享同一个 n，因为它们捕获的是 n 这个变量的地址，而非某个快照：

6.2 延迟语句

Mon, 01 Jan 0001 00:00:00 +0000

6.2 延迟语句

延迟语句 defer 在最早期的 Go 设计中并不存在，是后来才单独增补的特性，由 Robert Griesemer 完成语言规范的编写 [Griesemer, 2009]，Ken Thompson 完成最早期的实现 [Thompson, 2009]。它的语义读起来很短：被 defer 的调用会在外层函数返回、发生 panic、或调用 runtime.Goexit 时执行。直觉上这像是一个纯编译期特性，类似 C++ 的 RAII（离开作用域自动析构），编译器似乎只需把延迟的调用「搬」到函数末尾即可，不该有运行时开销。

真实情况要复杂一层。Go 的 defer 没有与某个资源的作用域绑定，还允许出现在条件、循环里，于是它不再是一个静态的作用域概念。一段执行次数取决于运行时的循环，能产生多少个延迟调用在编译期无法确定：

1
2
3
4
5


func randomDefers() {
	for rand.Intn(100) > 42 {
		defer println("golang-design/under-the-hood") // 次数运行时才定
	}
}

正因为存在这种不确定性，defer 不是免费的午餐。本节先讲清它的语义，再沿着一条贯穿十余年的性能演进主线，看它如何从「最慢时被劝退出热路径」一路优化到「几乎零成本」。这条主线的终点，也是理解 6.3 恐慌与恢复的钥匙：在今天的运行时里，正常返回时跑 defer 与 panic 展开时跑 defer，走的是同一套机器。

6.3 恐慌与恢复内建函数

Mon, 01 Jan 0001 00:00:00 +0000

6.3 恐慌与恢复内建函数

defer（6.2）已经把「函数退出时要做什么」交代清楚，留下的悬念是「函数被异常地打断时又会发生什么」。panic 与 recover 这对内建函数回答的正是这个问题：前者中断当前的正常控制流并开始沿调用栈向上展开，后者在展开途中把它截住。这一节先讲清它们的语义，再落到 go1.26 运行时里 gopanic、gorecover 的实现，最后回到一个更要紧的问题：panic 究竟该被当作什么，以及为什么 Go 没有把它做成 C++ 或 Java 那样的异常机制。

6.3.1 语义：展开、拦截与进程终止

panic 做三件事，顺序固定。它先停下当前函数余下的语句，转而按后进先出的次序执行当前 goroutine 已经登记的 defer 链；每执行一个延迟函数，控制权都短暂回到用户代码，给它一次拦截的机会；若整条链走完仍无人拦截，panic 会逐层弹出调用栈，到达 goroutine 栈顶后终止 整个进程，并打印 panic 值与栈回溯。

recover 是拦截的唯一手段，但它的生效条件很窄：只有直接被某个延迟函数调用时才有效。直接的意思是，调用 recover 的那一帧，必须正是发生 panic 的那一帧用 defer 登记的延迟函数本身，多一层嵌套或少一层都不算。一次成功的 recover 会让 panic 停止展开，返回当时传给 panic 的值，随后控制流如同那个延迟函数正常返回一般，继续往下走。

这条「同一调用链、且直接位于延迟函数中」的约束，是后文一切实现细节的根。先用三段代码把它落实。第一段，recover 写错了位置，拦不住：

1
2
3
4
5
6
7
8
9


func A() {
	B()
	C()
}
func B() {
	defer func() { recover() }() // 拦不住 C 的 panic：B 已经返回，不在展开路径上
	println("B")
}
func C() { panic("boom") }

A 先调用 B，B 正常返回、它的 defer 也早已执行完毕；随后 A 调用 C，C 发生 panic 时展开的是 C → A 这条路径，B 根本不在其上。第二段，把 recover 放到调用链上游的 A 里，就拦得住：

第 6 章 函数、延迟与恐慌 on Go 语言原本

6.1 函数调用

6.1 函数调用

6.1.1 函数值与闭包

6.2 延迟语句

6.2 延迟语句

6.3 恐慌与恢复内建函数

6.3 恐慌与恢复内建函数

6.3.1 语义：展开、拦截与进程终止

第 6 章函数、延迟与恐慌 on Go 语言原本