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。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 必须紧挨着
defer使用，常见写法是defer func() { if r := recover(); r != nil { ... } }() - recover 只能捕获**本 goroutine 当前正在传播的 panic**，无法捕获其他 goroutine 的 panic
- recover 成功后，panic 被“吞掉”，控制流回到 defer 所在函数的末尾，之后代码继续执行
func mayPanic() {
panic("boom")
}
<p>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: ..." ，而主流程早已结束。
