defer 在 return 写入返回值后、函数退出前执行；可修改命名返回值但无法影响匿名返回值；panic 时已注册 defer 仍执行，参数在注册时求值。
defer 不是在 return 语句“执行完”之后才跑，而是在 return 写入返回值后、函数真正退出前执行。 这个时间点很关键：它允许 defer 修改命名返回值，但无法影响匿名返回值；也意味着 panic 时 defer 仍会执行，但后续未注册的 defer 就彻底没机会了。
return 和 defer 的真实执行顺序
return 不是原子操作。它实际分三步：计算返回值 → 赋值给返回变量（或寄存器）→ 执行所有已注册的 defer → 跳出函数。所以 defer 看到的返回值已经是确定的，只是还没“交出去”。
- 命名返回值（如
func f() (x int)）在函数入口就声明为局部变量，return 3实际等价于x = 3，之后 defer 可以读写x - 匿名返回值（如
func f() int）没有绑定变量，return 3 + 4的结果直接进寄存器，defer 拿不到可修改的左值 - 如果函数中途
panic，return 不会触发，但已注册的 defer 依然全部执行
defer 参数在注册时就求值，不是执行时
这是闭包相关 bug 的高发区。比如循环中注册 defer，若直接捕获循环变量，所有 defer 拿到的都是最后一次迭代的值。
- 错误写法：
for i := 0; i → 输出全是 <code>3 - 正确写法：
for i := 0; i → 输出 <code>0、1、2 - 本质是参数绑定发生在
defer语句执行那一刻，和闭包捕获地址无关，是 Go 的明确语义
多个 defer 按 LIFO 顺序执行，不是代码书写顺序
Go 把每个 defer 压入栈，函数退出时从栈顶依次弹出。这在资源清理场景反而是优势：打开顺序和关闭顺序天然倒置。
-
defer db.Close()写在defer file.Close()后面？那db.Close()会先执行 - 常见误判：
defer fmt.Println("A"); defer fmt.Println("B")输出是B然后A，不是A然后B - 别靠缩进或注释猜执行顺序，看注册位置——越晚执行到的
defer语句，越早运行
defer 出现在 return 后面根本不会注册
这是语法硬限制。return 是控制流终点，它后面的代码（包括 defer）永远不会被执行到，更别说注册了。
- 下面的
defer永远不会生效：return err; defer cleanup() - 想做条件性延迟清理，必须把
defer放在return前，或封装进分支逻辑里，例如：if err != nil { defer cleanup() } - 已注册的 defer 不受影响，哪怕前面有
return—— 它们照常执行；但没走到的，就彻底没机会了
最易被忽略的是：defer 的注册时机（静态）和执行时机（动态）完全分离。你写下的每一行 defer，都在那一刻绑定了参数、压入了栈；而它的执行，要等到函数生命周期终结的那个精确切面——无论那是正常 return、走到函数末尾，还是 panic 触发。这个切面不可跳过，也不可延迟，但稍不注意，你就可能根本没把它注册进去。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
