defer 在函数即将退出前、return 写入返回值后、跳转前执行；所有退出路径（return、隐式结束、panic）均触发；可修改命名返回值，但参数在注册时求值。
defer 语句什么时候真正执行？
它不是“函数返回后才执行”，而是在函数**即将退出前、return 指令写入返回值之后、真正跳转出去之前**执行——这个时机点很关键，决定了 defer 能否读写命名返回值、能否捕获 panic 后的现场。
- 所有退出路径都触发 defer：显式
return、隐式结尾、panic（除非被os.Exit强制终止） -
return实际分三步：计算并赋值返回值 → 执行所有已注册的 defer → 跳出函数 - 这意味着：
defer中能修改命名返回值（如func f() (err error)），但对匿名返回值无效 - 常见错误现象：
defer fmt.Println(x)输出的不是x最终值，而是 defer 语句执行那一刻的值——因为参数在注册时就求值了
for 循环里 defer 引用 i 为什么全输出 3？
因为 i 是同一个变量地址，所有 defer 闭包捕获的都是它的指针，等真正执行时，循环早已结束，i == 3。
- 错误写法：
for i := 0; i → 输出三次 <code>3 - 正确做法一（绑定当前值）：
for i := 0; i - 正确做法二（传参进闭包）：
for i := 0; i - 注意：高频循环中大量创建匿名函数会增加 GC 压力，非必要不这么用
defer f.Close() 为什么会 panic？
因为 f 是 nil，或者 f 在 defer 注册后被重新赋值，导致 defer 关的是旧的（或空的）句柄。
- 必须先检查
err再 defer：f, err := os.Open(name); if err != nil { return }; defer f.Close() - 避免
f = nil或重赋值后还依赖原f；若逻辑中可能替换资源，应 defer 新实例 -
http.Response.Body.Close()尤其容易漏：只在成功路径 defer，错误分支没关 → 连接无法复用 - 更稳妥写法：
defer func() { if f != nil { f.Close() } }()，但优先靠流程控制避免 nil
多个 defer 的执行顺序为什么和代码顺序相反？
因为它们被压入一个栈，注册即入栈，执行时从栈顶弹出——所以后写的先执行，这是确定行为，不是 bug。
- 示例：
defer log.Print("A"); if cond { defer log.Print("B") }; for range xs { defer log.Print("C") }→ 输出顺序是C C B A - 资源清理要按“最后打开的最先关闭”反向配对：先
defer db.Close()，再defer file.Close()，实际关文件在前、关 db 在后 - 不要靠“写在上面就早执行”来安排逻辑，必须按 LIFO 反向思考；顺序敏感操作（如 unlock + close）建议合并进一个 defer 匿名函数
- panic 后仍按此顺序执行，这是可靠清理的基础，但 defer 本身不会阻止 panic 向上传播
最易被忽略的一点：defer 注册的是“调用动作”，不是“函数本身”。参数在 defer 那行就被求值，闭包捕获的是变量地址，接口/指针值变化会直接影响 defer 行为。这些细节不看运行时表现，只看代码很容易误判。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
