会执行，且仅执行panic前已注册的defer；Go在栈展开前强制按LIFO顺序执行所有已入栈defer，无论panic是否被recover捕获。
defer 在 panic 后照常执行，这是 Go 的确定性行为，不是“稳定性问题”，而是设计契约 —— 但很多人误以为它“可能不执行”或“执行顺序不可靠”，其实只要理解它的触发时机和栈展开逻辑，就能稳定依赖。
panic 触发后，defer 为什么一定执行？
Go 规定：只要 defer 语句在 panic 前已注册（即代码已执行到该行），它就一定会在当前 goroutine 栈展开过程中被执行，无论 panic 是由 runtime 错误（如 nil pointer dereference）还是 panic() 主动触发。
关键点在于：defer 不是“等函数 return 才跑”，而是绑定到当前函数的生命周期结束事件——包括正常 return、函数末尾隐式 return，以及 panic 导致的异常退出。
-
defer注册发生在语句执行时，不是函数调用时 - panic 发生后，Go 运行时会立即开始从 panic 点向上回溯，逐层执行每个函数已注册的
defer - 哪怕 panic 发生在第 1 行，只要前面有
defer，它就会被执行（前提是没被更早的 panic 中断）
defer 参数求值时机导致的常见陷阱
很多人发现 panic 后 defer 函数里打印的变量值“不对”，其实是混淆了参数求值时机：
defer fmt.Println(x) 中的 x 是在 defer 语句执行那一刻求值并拷贝，不是在真正调用 fmt.Println 时才读取。
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 如果写
x := 0; defer fmt.Println(x); x = 42; panic("boom")，输出是0，不是42 - 想捕获 panic 时的最新状态，得用闭包：
defer func() { fmt.Println(x) }() - 但注意：闭包捕获的是变量引用，若
x是指针或结构体字段，且后续被修改，闭包内看到的就是修改后的值
资源释放类 defer 在 panic 场景下的可靠性
文件关闭、锁释放、连接归还这类操作，正是 defer 最该用的地方 —— 因为 panic 并不影响它们的执行。
典型安全写法：
func processFile(path string) error {
f, err := os.Open(path)
if err != nil {
return err
}
defer f.Close() // 即使下面 panic，Close 也会执行
data, _ := io.ReadAll(f)
if len(data) == 0 {
panic("empty file not allowed")
}
return nil
}
-
f.Close()一定执行，避免 fd 泄漏 - 但要注意：如果
f.Close()本身 panic（比如底层 write buffer 出错），它会中断当前 defer 链，后续 defer 不再执行 - 多个
defer按后进先出（LIFO）顺序执行，所以加锁/解锁要配对出现在同一作用域
为什么有人觉得 defer “不稳定”？根本原因在这儿
所谓“学习稳定性差”，往往来自三类误判：
- 把跨 goroutine 的 panic 当成当前 goroutine 的 ——
go func() { panic("x") }()中的defer对主线程完全无感 - 把
recover()的失败当成defer失效 ——recover()本身必须在 defer 函数体内直接调用，否则返回 nil，但这不影响 defer 执行本身 - 在 defer 里调用了可能 panic 的清理逻辑（比如未判空的
mutex.Unlock()），导致二次 panic 掩盖原始错误
真正的稳定性瓶颈不在 defer 机制，而在开发者是否清楚它只作用于当前 goroutine、只响应本函数生命周期结束、且参数求值不可变。
