defer 在 panic 时会执行但不保证清理安全，因资源有效性、参数求值时机和上下文完整性影响其可靠性；os.exit 和信号退出会跳过 defer；正确做法是分离关注点、明确作用域与退出路径。
defer 在 panic 时确实会执行，但不等于“清理安全”
很多人看到文档说“defer 在函数返回前（包括 panic）执行”，就以为资源一定能被释放。这是个危险误解。defer 确实会运行，但它的安全性取决于三点：绑定的资源是否有效、参数求值是否及时、以及 panic 发生时上下文是否已破坏。
-
defer f.Close()如果f是 nil 或已提前Close()过，调用会 panic —— 而这个新 panic 可能掩盖原始错误，且 cleanup 失败 - 在循环中写
defer f.Close()却没把f闭包捕获，最终所有defer都关同一个（最后赋值的）文件句柄 -
defer log.Printf("done: %v", result)中result是变量名，不是值；若它在 defer 后被修改，日志里打的是最终值，不是你期望的“当时状态”
命名返回值 + 匿名函数 defer 是最易踩坑的组合
当函数声明为 func foo() (err error)，再在内部写 defer func() { err = fmt.Errorf("cleanup failed: %w", err) }()，看起来很酷，实际风险极高。
- 如果主逻辑里已经
return errors.New("read timeout")，defer 里又给err赋新值，最终返回的错误会被覆盖，上层无法区分是业务失败还是 cleanup 失败 - 更隐蔽的问题：若 cleanup 本身 panic（比如关闭一个已关闭的
*sql.Tx），整个函数会二次 panic，原始错误彻底丢失 - 正确做法是分离关注点：用普通变量记录 cleanup 结果，最后显式检查并合并，而不是靠命名返回值“自动注入”
多层 defer 堆叠 ≠ 更可靠，反而可能掩盖问题
有人觉得“多加几个 defer 总比少强”，比如在 main 函数里连写三段 defer 关 db、关 file、关 http client。这种写法看似全面，其实埋了雷。
-
defer db.Close()和defer f.Close()都依赖各自变量存活，但若db初始化失败导致db == nil，defer db.Close()就直接 panic，后续所有 defer 全部跳过 - 多个 defer 按 LIFO 执行，但它们之间无依赖关系 —— 如果关 db 必须在关 file 之后，仅靠顺序无法保证，得靠显式控制流
- 真正需要的是“可中断、可重试、可诊断”的清理链，而不是堆砌 defer。例如：用
sync.Once控制全局 cleanup，或用context.Context传递 cancel 信号
os.Exit 是 defer 的终结者，没有例外
无论你在 main 函数里写了多少 defer，只要中间某处调用了 os.Exit(1) 或 log.Fatal，所有 defer 立刻失效。这不是 bug，是设计使然 —— os.Exit 不走 return 路径，根本不给 defer 执行机会。
- 常见误用：在配置加载失败时直接
log.Fatal("config missing")，导致之前defer tmpDir.Remove()完全不触发，临时目录残留 - 替代方案不是“换 defer 写法”，而是根本避免
os.Exit：把主逻辑包进func run() error，让main统一处理 error 并自然 return —— 这样 defer 才有执行土壤 - 对信号退出（SIGINT/SIGTERM）也同理：不能靠
signal.Notify后直接os.Exit，必须用 channel 通知工作 goroutine 停止，等sync.WaitGroup归零后再 return
真正可靠的清理，从来不是靠 defer 数量堆出来，而是靠作用域清晰、变量绑定明确、退出路径唯一。越想“多重保险”，越容易因控制流断裂而全线失守。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
