defer 参数在声明时求值而非执行时：Go 遇到 defer 语句即对参数求值并保存副本，后续变量修改不影响已注册的 defer；循环中直接 defer 闭包会导致所有 defer 打印同一索引值。
defer 参数在声明时就求值，不是执行时
这是最常踩的坑：你以为 defer fmt.Println(i) 会打印最终的 i 值，结果却输出了注册时的旧值。因为 Go 在执行到 defer 语句那一行时，就立刻对参数求值并保存副本——哪怕后续 i 被修改，也不会影响已注册的 defer。
常见错误现象：
- 循环中直接
defer闭包，所有 defer 都打印同一个索引值（如for i := 0; i 输出 <code>2 2 2） - 变量更新后 defer 仍用旧值，导致日志或清理逻辑与预期不符
正确做法：
- 想延迟读取最新值，用匿名函数闭包：
defer func(){ fmt.Println(i) }() - 想传值而非引用，显式拷贝：
v := i; defer fmt.Println(v) - 对指针或 map/slice 等引用类型，要清楚你 defer 的是“当时指向的地址”，内容可能已被改写
多个 defer 按 LIFO（后进先出）顺序执行
这不是执行顺序“乱”，而是明确设计成栈行为：最后写的 defer 最先执行。这点直接影响资源释放顺序和锁嵌套逻辑。
立即学习“go语言免费学习笔记（深入）”；
使用场景：
- 打开文件 → 获取锁 → 分配内存，对应
defer file.Close()、defer mu.Unlock()、defer freeMem()—— 必须按相反顺序注册，才能保证释放不越界 - 嵌套锁时，外层锁必须比内层锁更晚
defer，否则提前解锁会引发竞态
容易忽略的细节：
-
defer不是“按代码位置从上到下执行”，而是“按注册时间从后往前弹出” - 如果在 if 分支里写
defer，它只在该分支执行时注册，不会影响其他路径 - 函数内多次调用同一资源的
defer（如重复defer conn.Close()），会导致 panic：close of closed channel / double-close
defer 在 return 之后、函数退出之前执行，能修改命名返回值
defer 不是插在 return 前面，而是插在 return 计算完返回值、但还没真正退出函数的那个瞬间。这个时机决定了它能“看到并修改”具名返回值。
示例对比：
func f1() (result int) {
result = 10
defer func() { result++ }()
return result // 返回 11
}
func f2() int {
result := 10
defer func() { result++ }()
return result // 返回 10（result 是局部变量，defer 修改它不影响返回值）
}
关键区别：
- 只有具名返回值（如
func() (x int)）才能被defer中的闭包修改 - 匿名返回值（如
func() int）的返回动作发生在defer之前，defer里改的是临时变量 - 这个机制常用于统一错误包装、日志记录、指标上报，但别滥用——会让返回逻辑变隐晦
defer 不会在 os.Exit 或 panic 未 recover 时执行
很多人误以为 defer “绝对可靠”，其实它只对当前函数的正常 return 和被 recover 捕获的 panic 有效。一旦触发 os.Exit 或未捕获的 panic，运行时会直接终止 goroutine，跳过所有 defer 链。
典型问题：
- 在主函数里调用
os.Exit(1)，之前注册的defer file.Close()不会执行，造成文件句柄泄漏 - 子 goroutine 发生 panic 且没 recover，其
defer全部失效，但主线程不受影响 - 测试中用
t.Fatal（底层调用os.Exit）导致 cleanup defer 被跳过
安全建议：
- 关键资源释放（如数据库连接池关闭、监听器 shutdown）不要只依赖
defer，应在主流程显式调用 - 避免在顶层
main函数里用os.Exit；改用return+ exit code - 写单元测试时，用
defer做 setup/cleanup 时，确保不触发t.Fatal类中断
