defer参数在注册时求值而非执行时，变量值被快照固化；需用闭包或指针实现延迟读取；循环中滥用会导致堆积和错值；命名返回值在defer中修改需谨慎。
Go里写defer不是“写完就跑”，它执行时机、参数求值、变量捕获都和直觉有偏差——不踩坑的前提是知道坑在哪、怎么绕。
defer参数在注册时就求值，不是执行时
这是最常被忽略的底层行为。你写的defer fmt.Println(i)，i的值在defer语句执行那刻就被拷贝进栈，后续改i不影响它。
- 如果想延迟读取最新值，得用闭包：
defer func() { fmt.Println(i) }() - 传指针会“现场直播”：如果
defer fmt.Println(&x)，执行时取的是*&x当前值，不是注册时快照 - 对结构体字段调用方法（如
m.print()）也属于“立即求值”，结果固化，不是动态调用
for循环里乱用defer会堆积+错值
每个defer都压入当前函数的defer链，循环1000次就压1000个，等函数退出才统一执行——既耗内存，又大概率输出全一样的数。
- 错误写法：
for i := 0; i → 输出<code>3 3 3 - 正确解法一（传参封存）：
defer func(n int) { fmt.Print(n) }(i) - 正确解法二（局部副本）：
n := i; defer fmt.Print(n) - 更推荐：把循环体抽成独立函数，在里面用
defer，避免defer链膨胀
defer里调用nil函数不会立刻panic
defer只是注册，不执行。哪怕defer nilFunc()，函数体照常跑完，直到return前才触发panic——这会让错误定位变难，日志里看不到panic发生点。
- 现象：
fmt.Println("done")能打印出来，之后才panic - 检查方式：对可能为nil的函数，先判空再defer：
if f != nil { defer f() } - 尤其注意接口方法返回函数时（如
db.connect()），别直接defer db.connect()，要接住返回值再defer
命名返回值在defer里被修改，但没生效
当函数声明了命名返回值（如func foo() (err error)），defer里写err = xxx看似能改返回值，但如果在if块里用:=重新声明err，就变成局部变量，原返回值不变。
- 陷阱代码：
if x > 0 { err := errors.New("bad") }→ 这里的err和返回值无关 - 正确写法：
if x > 0 { err = errors.New("bad") }（用=赋值，不带:） - 更安全做法：避免在defer里改命名返回值，改用显式
return err控制流
defer不是语法糖，它是运行时调度链上的一环；注册、压栈、求值、执行，每一步都有确定性规则。写之前先问自己：这个值现在就要拍快照，还是等最后才读？这个函数真能被调到，还是可能nil？这个defer真该在这儿，还是该挪进子函数里？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
