panic在defer中再次触发时，_panic链表在头部插入新节点，形成\_panicB→\_panicA→nil的倒序链表，最新panic在头、最早在尾；打印时则从尾到头遍历，按发生时间正序输出。
panic 在 defer 中再次触发时，_panic 链表怎么变
Go 运行时用单向链表管理当前 goroutine 的所有未恢复 panic，头指针存于 g._panic。每次调用 panic()，都会在链表头部插入一个新 _panic 结构体——不是覆盖，而是追加。所以递归 panic 本质是链表增长，而非“嵌套调用栈”式的压栈。
关键点在于：只有在 defer 函数执行期间触发的 panic()，才会让链表出现多个节点。因为正常函数返回路径不会重新进入 panic 流程；而 defer 是 panic 唯一能再次触发 panic 的入口。
-
panic()第一次调用 → 创建_panicA，g._panic指向它 - 开始执行 defer（比如
defer func() { panic("2nd") }()）→ 此时仍在_panicA处理流程中 - defer 内再调
panic()→ 创建_panicB，g._panic改为指向_panicB，其link字段指向_panicA
最终链表是 _panicB → _panicA → nil，顺序反映 panic 发生时间倒序（最新在前）。
recover 能捕获哪一层 panic
recover() 只作用于当前正在处理的那个 _panic，也就是 g._panic 指向的节点。它把该节点的 recovered 字段设为 true，并清空 g._panic（链表头被移除），但不会动 link 指向的旧 panic。
这意味着：
- 如果 defer 中两次 panic，且只在第二次 panic 后的 defer 里调
recover()，那么只有_panicB被标记 recovered，_panicA仍留在链表中（虽然已不是头） - 但程序不会继续执行后续 defer 或返回——
recover()成功后，panic 流程立即终止，控制权交还给 defer 所在函数的上层 - 未被
recover()的 panic（如_panicA）不会打印，也不会影响当前流程；它只是“悬空”在链表里，等 goroutine 退出时被忽略
panic 链表不为空但程序没崩溃，说明什么
这通常意味着：有 panic 发生过，某个 defer 执行了 recover()，但 recover() 调用位置不对，或者 panic 发生在 recover 作用域之外。
常见误判场景：
- recover 写在普通函数里，没包在 defer 中 → 总是返回
nil，无效 - recover 包在 defer 里，但 defer 注册在 panic 之后（比如
if err != nil { panic(err) }后才注册 defer）→ defer 根本没机会运行 - recover 执行时，
g._panic已为nil（比如上层已 recover 过），此时它什么也捕不到
调试时可检查 runtime.NumGoroutine() 是否异常增长，或用 go tool trace 观察 panic 事件是否被记录但未终止程序——那大概率是 recover 生效了，只是逻辑没处理好后续状态。
为什么 panic 打印信息时按发生顺序输出，而不是链表顺序
因为打印逻辑遍历的是 _panic 链表的尾部到头部，即从最早发生的 panic 开始，逐个顺着 link 字段往后走。源码里实际是先找到链表尾（通过反复取 p.link 直到为 nil），再反向回溯。
这个设计让错误日志更符合直觉：最先出问题的地方排第一，后续连锁反应排后面。但要注意：
- 如果中间某次 panic 被
recover()，它不会出现在最终 panic 日志里——只有那些recovered == false且仍挂在链表上的 panic 才会被打印 - 链表头是最新 panic，链表尾是最老 panic；打印顺序 = 尾 → 头，即时间正序
- 多级 panic 全部未 recover 时，你会看到类似
panic: 1\npanic: 2\npanic: 3，数字对应触发顺序
真正容易被忽略的是：recover 不会自动清理整个链表，只清当前头节点；而 panic 日志只扫未 recovered 的节点——这两点共同导致“链表非空但无输出”或“输出顺序与预期不符”的困惑。
