defer 在 return 赋值后、函数真正返回前执行；它插入在返回值写入返回位置与函数退出之间，此时命名返回值可被修改，非命名返回值则不可；多个 defer 按 lifo 顺序执行，参数在注册时求值。
defer 在 return 赋值后、函数真正返回前执行
结论很直接：defer 不在 return 语句“执行完”之后才跑，而是在 return 完成**返回值赋值**、但还没跳转出函数前执行。这个间隙，就是 defer 的唯一窗口。
常见错误现象：写 return x 后加 defer func() { x++ }()，发现返回值没变——因为 x 是局部变量，不是命名返回值；return x 已把 x 的当前值拷贝进返回槽，defer 再改 x 毫无意义。
- 命名返回值（如
func f() (r int)）：r是栈上真实变量，defer可读写，修改会影响最终返回值 - 非命名返回值（如
func f() int）：返回值是临时寄存器/栈槽，defer无法触达，改局部变量无效 -
return不是原子操作，它分三步：计算表达式 → 写入返回位置 → 函数退出；defer插在第二、三步之间
多个 defer 按 LIFO 顺序执行，注册顺序和执行顺序相反
你写的顺序，就是压栈顺序；函数退出时统一弹栈，所以最后注册的 defer 最先执行。
使用场景：资源清理必须逆序——比如先 os.Open 文件，再 sql.Open 数据库连接，那就要先 defer db.Close()，再 defer f.Close()，否则可能因 db 还开着导致文件句柄泄漏。
- 错误写法：
defer f.Close(); defer db.Close()→ 实际先关db，再关f，风险高 - 正确写法：按资源获取反序注册
defer，即后获取的先释放 - 性能影响极小，但大量
defer会略微拖慢函数退出路径（毕竟要逐个调用）
defer 参数在注册时求值，不是在调用时
这是闭包捕获变量出错的最高发点。写 defer fmt.Println(i)，i 的值在执行到这行 defer 时就被快照下来了，不是等函数返回时才读。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
典型陷阱：循环中注册多个 defer，共用同一个循环变量：
for i := 0; i <p>输出全是 <code>3</code>，因为三次 <code>defer</code> 都在循环结束时（<code>i == 3</code>）才注册，参数早已求值为 <code>3</code>。</p>
- 修复方式：用局部变量绑定当前值，如
defer func(v int) { fmt.Println(v) }(i) - 或直接在循环内声明新变量：
for i := 0; i - 注意：函数体本身延迟执行，但参数求值发生在
defer语句执行那一刻
panic 触发时已注册的 defer 仍会执行
panic 不会跳过已注册的 defer，这是 Go 的硬保证。只要控制流走到了某行 defer，它就一定会运行——哪怕后面紧跟 panic。
但未走到的 defer 不会注册，自然不执行。比如函数开头就 panic，后面所有 defer 都被跳过。
-
recover()必须在defer函数体内直接调用才有效；放在普通函数里毫无作用 -
defer中再panic会覆盖前一个 panic（除非外层已recover） - 资源清理类
defer（如Unlock、Close）在 panic 场景下依然可靠，这是它比 try/finally 更稳的地方
最易被忽略的是：命名返回值 + panic + defer 中 recover 的组合——recover 成功后，函数继续执行剩余 defer，然后正常 return，此时命名返回值可能已被多次修改，逻辑容易失控。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
