17370845950

defer 执行顺序为后进先出（LIFO），按注册逆序执行；参数在 defer 语句处即求值；在 r

eturn 写入返回值后、函数真正返回前执行，可修改命名返回值；panic 时仍执行，recover 必须在 defer 内调用。

defer 语句执行顺序是后进先出（LIFO）

多个 defer 语句在同一个函数中出现时，不是按书写顺序执行，而是按注册顺序的**逆序**执行。这点容易被直觉误导，尤其在嵌套或循环中注册 defer 时。

常见错误现象：以为先写的 defer fmt.Println("A") 会先打印，结果却是最后输出。

• 每次调用 defer 都会把函数和当时求值的参数压入当前 goroutine 的 defer 栈
• 函数返回前（包括 panic 后的 recover 过程），从栈顶开始依次执行
• 参数在 defer 语句执行时就完成求值（注意：不是执行时！），所以 i := 0; defer fmt.Println(i); i++ 打印的是 0

defer 与 return 的协作时机很关键

defer 在 return 语句“之后”但“函数真正返回之前”执行——准确说是：在 return 指令写入返回值、准备跳转前执行 defer 链。这使得 defer 可以修改命名返回值。

使用场景：资源清理 + 返回值修正，比如日志记录耗时、统一处理 error、关闭文件同时返回 err。

• 命名返回值（如 func foo() (err error)）在 defer 中可被修改；非命名返回值则不能
• 若函数 panic，defer 仍会执行，但 return 不会再发生；recover 必须在 defer 函数内调用才有效
• 不要在 defer 中调用 os.Exit() 或直接 panic，会跳过其余 defer

示例：

func f() (result int) {
	defer func() { result++ }()
	return 1 // 实际返回 2
}

defer 在循环中容易误用导致闭包陷阱

在 for 循环里写 defer 是常见需求（如批量关闭文件），但若直接引用循环变量，所有 defer 会共享最后一次迭代的变量值。

错误写法：

for i := 0; i < 3; i++ {
	defer fmt.Println(i) // 输出 3 次 "3"
}

• 根本原因是：i 是循环变量，地址不变，defer 捕获的是变量地址，而非值
• 正确做法：显式传参（defer fmt.Println(i) → defer func(x int) { fmt.Println(x) }(i)）或在循环内定义新变量（for i := 0; i ）
• 注意性能：频繁创建匿名函数可能带来小对象分配，高并发循环中需权衡

defer 不是万能的，该用 defer.Close 还是手动 close？

对实现了 io.Closer 接口的类型（如 *os.File、*sql.Rows），是否总该用 defer xxx.Close()？答案是否定的。

• 文件读写：建议 defer，因为 Close 失败通常不致命，且生命周期明确
• 数据库连接/事务：一般不用 defer，因为 Close 可能阻塞或失败，影响后续逻辑；应显式检查 err 并及时释放
• HTTP 响应体：resp.Body 必须 close，但应在读取完后立即 close，而非 defer —— 否则连接无法复用，造成连接池耗尽
• defer 的开销虽小（约 3–5ns），但在高频循环或性能敏感路径中，可考虑手动管理

容易被忽略的一点：defer 注册本身有微小成本，且它把资源释放推迟到函数退出，可能延长对象生命周期，影响 GC 时机。