panic仅影响当前goroutine，触发后按LIFO执行其defer；recover只在同goroutine的defer中有效，可捕获显式panic及多数运行时panic，但无法拦截Goexit、栈溢出等致命错误。

panic 触发后，当前 goroutine 立即停止执行后续代码，但会按 LIFO 顺序执行本 goroutine 中已注册的 defer 函数；若未被 recover 捕获，该 goroutine 崩溃，程序最终以非零状态退出。

panic 后 defer 一定执行，但仅限当前 goroutine

Go 的 panic 不会跨 goroutine 传播。它只影响触发它的那个 goroutine，并在退出前强制执行该 goroutine 内所有已声明（且尚未执行）的 defer 语句。

• defer 执行顺序严格遵循“后进先出”：最后声明的 defer 最先运行
• 即使 panic 发生在 defer 函数内部，只要它属于同一 goroutine，仍会继续执行更早注册的 defer
• 其他 goroutine 完全不受影响——它们不会执行你的 defer，也不会自动 recover

func main() {
    defer fmt.Println("main defer 1")
    defer fmt.Println("main defer 2")
    go func() {
        defer fmt.Println("goroutine defer") // 这个会执行
        panic("in goroutine")
    }()
    time.Sleep(100 * time.Millisecond) // 避免 main 提前退出
}

输出中你会看到 "goroutine defer"，但看不到 "main defer 1" 或 "main defer 2" ——因为 panic 在子 goroutine 中，main 的 defer 不会被触发。

recover 只能在 defer 中生效，且必须在同 goroutine

recover() 是唯一能拦截 panic 的函数，但它只有在 defer 函数中调用才有效；如果放在普通逻辑里，返回值恒为 nil。

• 必须紧挨着 defer 使用，常见写法是 defer func() { if r := recover(); r != nil { ... } }()
• recover 只能捕获**本 goroutine 当前正在传播的 panic**，无法捕获其他 goroutine 的 panic
• recover 成功后，panic 被“吞掉”，控制流回到 defer 所在函数的末尾，之后代码继续执行

func mayPanic() {
    panic("boom")
}
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("recovered:", r) // 输出: recovered: boom
}
}()
mayPanic()
fmt.Println("this runs") // 这行会执行
}

哪些 panic 根本无法 recover？

绝大多数运行时 panic（如空指针解引用、切片越界、除零）和显式 panic() 都可被 recover 拦截。但以下两类不行：

• runtime.Goexit() 引发的退出：它不触发 panic，而是直接终止 goroutine，defer 仍执行，但 recover 无效
• 致命错误（fatal error），比如栈溢出、内存耗尽、runtime.throw 直接调用的底层崩溃（如 "fatal error: all goroutines are asleep - deadlock"）

这类错误没有 panic value，也没有调用栈可 recover，程序直接中止，连 defer 都可能来不及执行完。

最常被忽略的一点是：recover 不是全局异常处理器。你得在每个可能 panic 的 goroutine 里手动加 defer + recover，否则子 goroutine panic 就是静默崩溃——日志里可能只有一行 "panic: ..." ，而主流程早已结束。