defer按后进先出顺序执行，注册时立即求值参数并入栈，返回前弹出执行；捕获变量地址而非值，需注意循环中复用变量问题；仅作用于当前goroutine，无法跨协程或传播panic；Close等需显式处理error，高频路径应避免滥用。
defer 会按后进先出顺序执行，不是写在哪儿就立刻执行
很多人以为 defer 是“等函数返回时才调用”，但没意识到它注册的时机是语句执行时，且多个 defer 会压栈——最后写的最先执行。这直接影响变量捕获和资源释放逻辑。
- 函数内每遇到一条
defer语句，Go 就立即求值其参数（注意：是参数值，不是变量本身），并把该调用入栈；函数真正返回前再依次弹出执行 - 如果
defer调用的是闭包或带变量引用的函数，要注意：捕获的是变量的**当前地址**，不是快照值。例如i在循环中被复用，所有defer可能都打印最后一个i的值 - 常见修复方式：在
defer外层加一层作用域，比如for i := range xs { go func(i int) { defer fmt.Println(i) }(i) }——但更推荐直接传参：defer fmt.Println(i)（前提是i是值类型且你希望捕获当时值）
defer 不能跨 goroutine 生效，也不能拦截 panic 后的非 defer 清理逻辑
defer 只对当前 goroutine 的函数生命周期有效。一旦启动新 goroutine，它的 defer 和父函数完全无关；而 panic 发生后，只有当前函数的 defer 会被执行，不会自动传播到调用方。
- 不要在
go func() { defer close(ch) }()中依赖defer关 channel——goroutine 退出不等于函数返回，defer不触发 - 若想 panic 后仍做清理，必须在同层函数里写
defer，且确保它在panic之前注册。例如defer unlock(); lock(); if err != nil { panic(err) }是安全的；反过来就漏释放 -
recover()必须在defer函数内部调用才有效，单独写recover()没用
文件/锁/数据库连接要 defer，但注意 Close() 返回 error 很可能被忽略
用 defer f.Close() 看似简洁，但 Close() 可能返回 error（比如写缓冲失败），而 defer 不提供 error 处理出口，容易掩盖问题。
- 标准做法是显式检查：
defer func() { if err := f.Close(); err != nil { log.Printf("close failed: %v", err) } }() - 对
sync.Mutex，defer mu.Unlock()安全，但需确保mu.Lock()已成功执行（否则 Unlock panic） - 数据库
*sql.Tx常见错误：在事务函数里defer tx.Rollback()，却忘了在 Commit 成功后手动tx.Commit()并 return——结果 Rollback 总被执行。正确模式是defer func() { if !committed { _ = tx.Rollback() } }()
defer 有开销，高频小函数里别滥用
每次 defer 注册都会分配一个 _defer 结构体（含函数指针、参数拷贝、链表指针），在函数返回时还要遍历 defer 链表。对微秒级函数，这个开销不可忽视。
立即学习“go语言免费学习笔记（深入）”；
- 基准测试显示：空函数加 1 个
defer，耗时增加约 20–30 ns；5 个可到 100 ns 以上 - 在 tight loop 内部、或 hot path 上的工具函数（如 JSON 解析中的字段处理），优先用显式
if err != nil { cleanup(); return err } - 编译器对单个
defer有优化（如内联），但多个或带闭包的几乎无优化空间
真正难的不是记住 defer 的语法，而是判断「此刻该不该 defer」——它本质是把控制流从显式跳转变成隐式栈管理。参数求值时机、panic 恢复边界、error 处理缺口、性能敏感路径，这些地方稍不留意就会埋下静默故障。
