答案：panic堆栈是崩溃现场快照，含panic值、goroutine ID/状态及自底向上调用链；需在defer+recover后立即调用runtime.Stack(buf, false)捕获并记录，否则丢失上下文。
panic 堆栈信息不是日志，而是程序崩溃时的“现场快照”——它不告诉你为什么出错，只告诉你错在哪儿、谁调用了谁、当前 goroutine 正在执行哪一行。线上排障真正卡住人的，从来不是看不懂 panic 本身，而是漏掉了调用链上下文、goroutine 状态、或 recover 后没保留关键信息。
panic 默认打印的堆栈到底包含哪些内容
Go 运行时在未被 recover 捕获的 panic 发生后，会自动调用 runtime.Stack 打印错误信息。默认输出包含三块核心内容：
- 第一行是 panic 的参数值，比如
panic("database timeout")或panic(0) - 紧接着是
goroutine N [status]:，其中N是 goroutine ID，[status]是当前状态（如running、syscall、chan receive） - 调用栈从下往上展开：每行形如
main.doWork(0x4b14a0)，含函数名、源码文件路径、行号（如果有调试信息）、以及汇编偏移量
注意：runtime.Stack 默认只输出当前 goroutine 的栈；若 panic 由 channel 死锁或 goroutine 泄漏引发，单看这一个栈可能完全找不到根因。
如何在 recover 中完整捕获并记录调用栈
单纯用 recover() 拿到 panic 值远远不够。必须立刻调用 runtime.Stack 抓取当前 goroutine 的完整栈帧，并和请求上下文（如 RequestID）一起写入日志。否则 recovery 就等于“静默丢弃故障”。
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.Stack(buf, false)获取当前 goroutine 栈（false表示仅当前，性能好、噪音少） - buf 需预分配足够空间（建议至少 4KB），否则截断后无法定位深层调用
- 必须在 defer 函数内、
recover()之后立即执行，否则栈可能已被 runtime 清理 - 别忘了把
RequestID、HTTP 方法、路径等上下文一并打点，否则日志查不到对应请求
示例关键片段：
defer func() {
if r := recover(); r != nil {
var buf [4096]byte
n := runtime.Stack(buf[:], false)
log.Printf("PANIC in request %s: %v\n%s", reqID, r, buf[:n])
}
}()
recover 后为什么有时 still crash？常见失效场景
recover 不是万能开关，它只对“当前 goroutine 中正在传播的 panic”生效。以下情况它完全无效：
- 在非 defer 函数中调用
recover()—— 返回nil，且无任何提示 - panic 发生在其他 goroutine（比如 http handler 启动的子 goroutine），而
recover写在主 goroutine 里 - recover 执行前，已有 defer 函数 panic 了两次（
_panic链表里有多个节点），而 runtime 只处理最顶层那个 - recover 被包裹在嵌套函数里，但外层 defer 没有触发（比如 defer 被条件跳过）
特别注意：Go 1.22+ 对嵌套 panic 的处理更严格，连续两次 panic 且未 recover 时，第二个 panic 会直接终止进程，绕过所有 defer。
线上服务要不要全局 recover？权衡点在哪
HTTP 服务入口加一层 defer + recover 是常见做法，但它不是“兜底”，而是“止损”。关键判断依据是：
- 是否允许该 panic 影响其他请求？—— 若 panic 来自共享资源（如全局 map 未加锁），recover 后继续跑可能引发数据污染
- 是否具备完整的上下文采集能力？—— 没有
RequestID和栈快照的 recover 日志，基本无法复现 - 是否掩盖了本该提前暴露的设计缺陷？—— 比如频繁 panic 的
nil解引用，应该 fix bug，而不是加 recover
真正容易被忽略的是：recover 后的程序状态是未知的。函数局部变量可能已部分修改，channel 可能已关闭，mutex 可能仍被持有。强行继续执行，比直接崩溃更危险。
