recover只能捕获最内层panic，因为Go运行时用单向链表管理_panic结构，每次panic()在链表头追加新节点，recover()仅清空并返回头节点值，后续panic若未被拦截则继续向上展开。
panic 嵌套时为什么 recover 只能捕获最内层？
因为 Go 运行时用单向链表管理当前 goroutine 的 _panic 结构，每次调用 panic() 都会在链表头部追加新节点，而不是覆盖。但 recover() 只会清空链表头节点（即最近一次 panic），并返回其值；后续 panic 仍留在链表中，若没被新的 recover() 拦截，就会继续向上展开。
常见错误现象：在 defer 里连续调用两次 panic("a") 和 panic("b")，只打印 “a”，程序却因 “b” 崩溃——说明第一次 panic 被 recover 后，第二次 panic 未被捕获，直接逃逸。
- recover() 必须在 defer 函数体内直接调用，不能包在子函数里
- 嵌套 panic 不是“压栈嵌套”，而是链表追加；recover 不是清空整个链表，只取头
- 如果 defer 中 recover 后又 panic，且外层无对应 recover，程序仍会终止
defer 注册顺序和 panic 展开顺序不一致的坑
很多人以为 defer 的执行顺序取决于书写位置，其实它取决于注册时机：每个 defer 语句执行时，就把对应函数压入当前函数的 defer 栈；panic 触发后，按 LIFO（后进先出）顺序弹出执行。这意味着，defer fmt.Println("1") 写在前面，defer fmt.Println("2") 写在后面，实际输出是 “2” 然后 “1”。
典型误用场景：资源释放逻辑写反，比如先 defer db.Close()，再 defer tx.Commit()，结果 tx 还没提交，连接就关了。
立即学习“go语言免费学习笔记（深入）”；
- 参数在 defer 注册时就求值，不是执行时；循环中 defer 引用循环变量，所有 defer 都拿到最后一次值
- panic 发生点之后的 defer 不会被注册，自然不执行；只有已注册的 defer 才参与 unwind
- 命名返回值可在 defer 中修改，非命名返回值（如
return 42）则不可变
recover 失效的三种典型写法
recover() 是个“一次性开关”，只在 defer 函数体内、且 goroutine 处于 panic 状态时才有效。写错位置或时机，它就永远返回 nil。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
常见失效写法：
-
defer recover()：这是在注册时就调用了 recover，此时无 panic，必返回 nil -
defer func() { r := recover(); ... }()正确；但写成defer helper()，而helper()内部调 recover → 无效 - 在子 goroutine 里 panic，main 里 defer recover → 跨 goroutine，无法捕获
注意：recover() 成功后，panic 链表头被移除，但函数仍会继续执行完剩余 defer，然后正常 return —— 它不是“重放函数”，只是停止 unwind。
什么时候该用 panic，什么时候该用 error？
Go 的设计哲学很明确：error 用于可预期、可恢复的问题（比如文件不存在、网络超时）；panic 仅用于真正致命、不该继续执行的场景（比如 nil 指针解引用、数组越界、初始化失败）。滥用 panic 会让调用方失去控制权，也违背 Go 显式错误处理的本意。
容易被忽略的边界点：
- 标准库中
json.Unmarshal返回 error，不 panic；但template.Must在编译失败时 panic —— 因为模板错误应在启动时暴露，而非运行时静默失败 - HTTP handler 中绝不应让 panic 逃逸到 net/http，必须用 defer+recover 封装，否则连接可能卡住或响应中断
- 测试代码里用
panic模拟异常没问题，但生产代码中手动panic("not implemented")属于设计缺陷，应改用 error
真正难的不是语法，而是判断哪个错误值得 panic —— 它不是“更严重的 error”，而是“程序状态已不可信”的信号。
