Go 的 defer 按注册顺序后进先出（LIFO）执行，非代码书写顺序；panic 不中断已注册 defer 但跳过未注册的；闭包捕获变量引用需显式传参或绑定局部变量；多资源释放须逆序注册或封装 cleanup。
defer 释放资源时，为什么顺序和 panic 场景下表现不一致？
Go 的 defer 是后进先出（LIFO）执行的，但很多人误以为“写在前面的 defer 就先执行”——其实只看调用时机，不看代码位置。真正决定顺序的是 defer 语句**实际被执行的时刻**，而非声明顺序。比如在循环中多次 defer 同一个函数，每次调用都会入栈；而如果某个 defer 调用被条件跳过（如 if err != nil { return } 前没 defer），那它根本不会注册。
更关键的是：panic 不会中断已注册的 defer 链，但会跳过尚未执行的 defer（包括同函数内后续未走到的 defer 语句）。这意味着资源释放逻辑必须全部提前注册，不能依赖“流程走到某处才 defer”。
- 文件打开后立即
defer f.Close()，而不是等所有处理完成再统一 defer - 数据库连接、锁、临时目录、goroutine 信号 channel 都需在获取后立刻 defer 清理
- 避免在 defer 中调用可能 panic 的函数（如未判空的
close(ch)），否则会掩盖原始 panic
多个资源嵌套时，如何避免 defer 闭包捕获错误变量值？
这是最常踩的坑：defer 中的闭包捕获的是变量的**引用**，不是快照。循环中写 for _, f := range files { defer os.Remove(f) }，最终所有 defer 都删最后一个 f 的值。
正确做法是显式传参或用局部变量绑定：
立即学习“go语言免费学习笔记（深入）”；
- 用函数参数固化值：
for _, f := range files { defer func(name string) { os.Remove(name) }(f) } - 或引入新作用域：
for _, f := range files { f := f; defer os.Remove(f) } - 对非循环场景，也建议把资源句柄作为参数传给封装好的 cleanup 函数，比如
defer cleanupFile(f)，避免直接在 defer 中写长表达式
需要按特定顺序释放（如先关 DB 连接，再删临时文件）时，能否靠多个 defer 控制？
可以，但必须严格按逆序注册。比如要实现 “关闭监听 socket → 关闭 DB → 删除临时目录”，就得这样写：
func serve() {
tmpDir, _ := os.MkdirTemp("", "srv-")
db, _ := sql.Open("sqlite", "test.db")
ln, _ := net.Listen("tcp", ":8080")
defer os.RemoveAll(tmpDir) // 最后执行
defer db.Close() // 第二执行
defer ln.Close() // 最先执行
}
注意：这不是“写在上面就先执行”，而是“ln.Close() 最晚注册，所以最先执行”。如果你把 defer db.Close() 放在 defer ln.Close() 后面，它反而会比 ln.Close() 更早执行。
- 复杂释放逻辑建议封装成单个
defer cleanup()，内部按需顺序调用各子清理函数 - 避免跨函数传递多个 defer，容易失控；同一函数内控制顺序最可靠
- 若涉及异步资源（如 goroutine + channel），确保 defer 中
close(ch)前无其他 goroutine 正在向其发送
defer 在 HTTP handler 或 long-running goroutine 中是否安全？
不总是。HTTP handler 中 defer 很常用，但要注意：handler 返回后，responseWriter 可能已被刷新或关闭，此时 defer 中再写 header 或 body 会 panic（http: wrote after response.WriteHeader）。同样，goroutine 中 defer 的生命周期只到该 goroutine 结束，若它长期运行且持有资源，defer 并不能防止泄漏。
- HTTP handler 中，仅对 request-scoped 资源（如解析 JSON 的
io.ReadCloser、临时 buffer）用 defer；响应相关操作不要 defer - goroutine 中，若启动了子 goroutine 处理任务，主 goroutine 的 defer 不会等待子 goroutine 结束——得用
sync.WaitGroup或context协同 - defer 不替代显式错误检查：比如
db.QueryRow().Scan()失败后，仍要手动 closerows，不能只靠 defer
多资源顺序释放不是靠堆砌 defer，而是靠注册时机、变量绑定、执行顺序这三点卡死。最容易忽略的是：defer 不是“延迟执行”，而是“延迟注册+逆序执行”，一旦理解错这个机制，后面所有设计都会偏航。
