defer 语句捕获定义时变量的快照而非执行时的值，如 for 循环中 defer fmt.println(i) 会全部输出循环结束后的 i 值。
Defer 语句在函数返回前才执行，但变量捕获的是定义时的值
很多人以为 defer 是“函数结束时取当前变量值”，其实它捕获的是声明那一刻的变量快照。比如闭包里用循环变量，或者对指针/接口做延迟调用，容易拿到意外的值。
常见错误现象：defer fmt.Println(i) 在 for i := 0; i 中输出全是 <code>3；或 defer f.Close() 在 f 被重新赋值后仍关闭旧文件描述符。
- 想延迟执行时用最新值？显式传参：
defer func(x int) { fmt.Println(x) }(i) - 操作指针或接口资源（如
*os.File），确保defer绑定的是最终要释放的那个实例 - 避免在循环中直接 defer 涉及迭代变量的操作，除非你明确需要“定义时刻”的值
多个 Defer 的执行顺序是 LIFO（后进先出），不是代码书写顺序
defer 堆栈行为和调用栈一致：最后声明的最先执行。这在嵌套资源清理、锁释放、日志记录等场景直接影响逻辑正确性。
使用场景：打开文件 → 加锁 → 写日志 → 返回，对应清理应是：写日志（收尾）→ 解锁 → 关文件（最外层资源）。
立即学习“go语言免费学习笔记（深入）”；
- 别靠“写在上面就先执行”来安排顺序，必须按 LIFO 反向思考
- 如果依赖顺序敏感（比如先 unlock 再 close），把它们拆成独立 defer，或合并进一个匿名函数里统一控制
- 注意 panic 后的 defer 依然按 LIFO 执行，这是恢复和清理的关键机制
Defer 不会阻止 panic 传播，但能确保资源释放
有人误以为加了 defer 就能“兜住 panic”，其实它只保证执行时机，不改变控制流。panic 发生后，所有已注册的 defer 仍会执行，但之后仍向上抛出。
性能影响：每个 defer 有微小开销（注册函数、保存参数、维护链表），高频路径（如 tight loop 或 hot handler）中大量使用会影响性能。
- 关键资源（文件、DB 连接、mutex）必须 defer，哪怕有 panic 风险
- 非关键日志或统计类 defer，在压测中发现占比高时可考虑移出 hot path
- 不要用 defer 做错误处理替代 return 或 recover —— 它不是 try/catch
HTTP Handler 中 defer 关闭 response body 容易漏掉或重复关闭
Go 标准库的 http.Response.Body 必须手动 Close()，但新手常在 if err != nil 分支外写 defer，导致错误路径下没关；或在多个 return 点都写 defer，引发 double-close panic。
兼容性影响：某些 HTTP 客户端（如 http.Transport 复用连接）依赖 Body 正确关闭才能复用底层 TCP 连接。
- 统一放在函数开头：
defer resp.Body.Close()，再检查resp是否为 nil（比如请求失败时resp可能是 nil） - 更稳妥写法：
if resp != nil && resp.Body != nil { defer resp.Body.Close() } - 别在 error 分支里另起 defer —— 用一个位置覆盖所有出口
defer 最难的不是语法，而是判断“这个值此刻是不是我要的那个实例”，以及“这个顺序是不是真符合资源生命周期”。稍不注意，关错文件、锁没解、body 漏关，问题都藏在看似安全的延迟里。 
