recover只能捕获最内层panic的值，defer按LIFO顺序执行，panic时栈展开不可干预；recover无法区分panic层级，需用结构体封装上下文；HTTP handler必须在入口处defer recover，goroutine内panic需内部处理。
panic 嵌套调用时，recover 只能捕获最内层 panic 的值，且 defer 执行顺序严格遵循 LIFO（后进先出）——这不是“嵌套处理”，而是栈展开的自然结果。
panic 发生时 defer 的执行顺序是固定的
当函数 A 调用 B，B 调用 C，C 中触发 panic，Go 会立即停止 C 的执行，然后按调用栈逆序执行每个函数中已注册的 defer：先执行 C 中的 defer，再 B，最后 A。这个顺序不可干预，也不受“嵌套”表象影响。
-
defer语句在函数进入时就注册进当前 goroutine 的 defer 链，不是在 panic 时才收集 - 即使 A、B、C 都有
defer func() { recover() }()，只有 C 中那个在 panic 发生前已注册的recover()会生效；A 和 B 的recover()根本不会被调用，因为 panic 在 C 就被截断并返回了 - 错误写法：
func A() { defer recover(); B() }→ B 中 panic 后，A 的 defer 确实会执行，但此时 panic 已传播到 B 的栈帧并被 B 自己的 defer 捕获（如果有的话），A 的recover()收不到任何值，返回nil
recover() 只能拿到当前 panic 的值，无法区分“哪一层抛的”
recover() 返回的是 panic() 实参的原始值（interface{}），不带调用栈信息或层级标记。你无法从 r := recover() 推断出它是来自 C 还是来自 B，除非你在 panic 时主动携带上下文：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 推荐做法：用结构体封装 panic 值，例如
panic(struct{ Src string; Err error }{"in C", io.EOF}) - 避免用裸字符串或 error 类型直接 panic，否则日志里只能看到
"index out of range"，不知道发生在哪个 handler 或哪个循环迭代中 -
runtime/debug.Stack()可在recover分支里调用，但它返回的是 panic 发生点的完整堆栈，不是“嵌套路径”
HTTP handler 中常见嵌套 panic 场景与修复
典型场景：主 handler 调用校验函数 → 校验函数 panic → handler 里没 defer → 请求静默失败。这不是嵌套问题，是 recover 缺位：
立即学习“go语言免费学习笔记（深入）”；
- 必须在 handler 入口处加
defer func(){ recover() }()，而不是等它调用的子函数自己 recover - 子函数内部 panic 是为了快速退出，但 recover 必须由调用方（handler）承担，因为 HTTP 连接生命周期绑定在 handler goroutine 上
- 若 handler 内起
go func(){ ... panic(...) }()，这个 panic 完全独立，主 handler 的 defer + recover 捕获不到——得在 goroutine 内部自己加 defer
真正容易被忽略的不是“嵌套怎么处理”，而是：recover 必须出现在 panic 的调用路径上，且必须早于 panic 注册；一旦 panic 展开结束，就没有“恢复”这回事，只有日志、降级、退出。堆栈不是用来“恢复执行”的，是用来定位为什么那里会 panic。
