defer 在当前函数 return 语句执行前、返回值已确定后执行；命名返回值可被 defer 修改，临时返回值则不能；多个 defer 按 LIFO 顺序执行；参数在 defer 定义时求值，函数体延迟执行；不宜用于耗时或可能 panic 的操作。
defer 语句的执行时机很关键
defer 不是“函数结束时才执行”，而是“当前函数 return 语句执行前、但所有返回值已确定后”执行。这意味着：如果函数有命名返回值，defer 中修改该变量会影响最终返回结果；但如果返回的是临时值（如 return x + 1），defer 就改不了它。
常见错误是以为 defer 在 return 后才跑，结果发现日志没打、锁没释放、文件没关闭——其实是因为函数 panic 或提前 return 导致 defer 还没轮到就退出了（但 panic 时 defer 仍会执行）。
多个 defer 的执行顺序是 LIFO（后进先出）
Go 把 defer 语句压入栈，所以越晚写的 defer 越早执行。这在资源清理场景中非常自然：先开文件，再加锁，最后 defer 关闭和解锁，代码顺序和执行顺序刚好反着，逻辑更清晰。
defer fmt.Println("A")defer fmt.Println("B")fmt.Println("C")
输出是：C → B → A。注意：defer 语句本身在定义时就对参数求值（比如 defer fmt.Println(i) 中的 i 是当时值），但函数体延迟到真正执行时才调。
立即学习“go语言免费学习笔记（深入）”；
defer 和命名返回值一起用要小心
命名返回值相当于在函数开头声明了变量，return 语句会先给这些变量赋值，再触发 defer，最后返回。所以 defer 可以读写它们：
func f() (result int) {
defer func() { result *= 2 }()
return 3 // 实际等价于 result = 3; 然后执行 defer; 最后 return result
}
这个函数返回 6。但如果 return 的是表达式（如 return 3 + 4），就没有命名变量可改，defer 就无法影响返回值。
容易踩的坑：在 defer 里 recover 时，如果忘了命名返回值，recover 后的 return 会被外层 return 覆盖——因为 recover 不等于 return，它只是让 panic 停止传播。
defer 不适合做耗时或可能 panic 的操作
defer 在函数末尾集中执行，如果某个 defer 耗时长（比如网络请求、大文件写入），会拖慢整个函数返回，还可能掩盖真正的错误点。更严重的是：defer 里再 panic，会导致程序直接崩溃（因为 recover 只捕获当前 goroutine 的 panic，且必须在 defer 函数内调用）。
建议只用 defer 做轻量、确定成功的事：关文件、解锁、重置状态。复杂逻辑拆出来显式调用，别塞进 defer。
实际项目里最容易被忽略的是 defer 的参数求值时机和命名返回值的耦合——这两点一旦理解偏差，bug 很难复现，尤其在并发或 panic 场景下。
