defer 是“延迟注册”而非“延迟调用”，在函数 return 后、栈帧销毁前执行；执行顺序为 LIFO，多个 defer 按出现顺序入栈、逆序执行；循环中直接 defer fmt.Println(i) 会打印终值，应改用 defer func(v int){}(i) 或局部变量。
defer 不是“延迟调用”，而是“延迟注册”，真正执行时机在函数 return 之后、栈帧销毁之前。
defer 的执行顺序是 LIFO（后进先出）
多个 defer 语句按出现顺序压入栈，但弹出执行时是逆序。这和很多人直觉相反，尤其当 defer 带有变量捕获时容易出错。
常见错误现象：defer fmt.Println(i) 在循环中打印的全是最后一个值 —— 因为所有 defer 都引用了同一个变量 i，而执行时 i 已经变成终值。
- 正确做法：用局部副本传参，例如
defer func(v int) { fmt.Println(v) }(i) - 或在循环内声明新变量：
for i := 0; i - 注意：
defer注册的是函数值 + 当前参数值（非引用），但若参数是闭包或指针，则仍可能共享状态
defer 在 panic/recover 场景下的行为
即使发生 panic，已注册的 defer 仍会执行，且在 recover 之后才继续向上传播 —— 这是 Go 实现资源清理的关键机制。
立即学习“go语言免费学习笔记（深入）”；
使用场景：文件关闭、锁释放、数据库事务回滚等必须兜底的操作。
-
defer函数内部若也panic，会覆盖当前 panic（除非用recover拦截） - 多个
defer中只有最外层能recover到本次 panic；内层defer的recover会返回nil - 不要依赖
defer做“错误处理”，它只保证执行，不改变控制流逻辑
defer 对返回值的影响（named return + defer 修改）
当函数使用命名返回值（如 func f() (err error)），且 defer 中修改该变量，会影响最终返回值 —— 因为命名返回值在函数入口就已分配内存，defer 可直接写入。
性能影响：这种写法会让编译器无法做某些优化（如返回值逃逸分析更激进），且可读性差，调试困难。
- 示例：
func f() (x int) { x = 1; defer func() { x = 2 }(); return }→ 返回 2 - 等价于：return 前隐式插入
x = 1，然后执行所有defer，最后返回x - 避免在
defer中修改命名返回值；如需副作用，改用普通变量 + 显式 return
真正容易被忽略的是：defer 的注册发生在语句执行时，而非函数定义时；这意味着条件分支里的 defer 是否注册，取决于运行时路径 —— 有人误以为“写了 defer 就一定执行”，其实它根本没被注册进去。
