如何在Golang中处理并发中的Panic Go语言Goroutine安全退出机制

goroutine panic 不会传播到主 goroutine，仅终止自身并打印 stack trace 到 stderr；必须在每个 goroutine 内部用 defer+recover 捕获，且 recover 仅对同 goroutine 有效。

Go 中 goroutine panic 后会自动终止，但不会传播到主 goroutine

这是最常被误解的一点：启动的 goroutine 里发生 panic，主程序照常运行，甚至可能悄无声息地“漏掉”错误。你看到程序没报错、也没按预期结束，大概率就是某个子 goroutine panic 了但没人 recover。

根本原因在于 Go 的 panic 是 goroutine 局部的 —— 它不会跨 goroutine 传播，也不会触发 os.Exit 或中断其他 goroutine。

• 常见错误现象：panic: runtime Error: invalid memory address 出现在日志里，但主流程仍在跑，http 服务没挂，定时任务还在执行
• 典型场景：HTTP handler 里启了个匿名 goroutine 做异步写日志，里面用了未初始化的指针；或 time.AfterFunc 回调里访问了已释放的 Struct 字段
• 不加 recover 的 goroutine panic 只会打印 stack trace 到 stderr（如果没重定向，你可能根本看不到）

用 defer + recover 捕获 goroutine 内 panic

必须在每个可能 panic 的 goroutine 内部做 recover，不能指望外面包一层。这是唯一可靠的方式。

注意：recover 只在 defer 函数中有效，且只对同 goroutine 的 panic 生效。

立即学习“go语言免费学习笔记（深入）”；

• 正确写法是把 defer func() { if r := recover(); r != nil { /* 记录/上报 */ } }() 放在 goroutine 函数体第一行
• 别写成 go func() { defer recover() }() —— recover 不是函数调用，单独写没意义
• 别在外部 goroutine 里对另一个 goroutine 调用 recover —— 它永远返回 nil
• 示例：

  go func() {     defer func() {         if r := recover(); r != nil {             log.Printf("goroutine panic: %v", r)         }     }()     // 可能 panic 的逻辑，比如 map 并发读写、空指针解引用等     doSomethingRisky() }()

结合 context 实现带超时/取消的 goroutine 安全退出

recover 解决 panic，但解决不了“卡死”或“该停不停”。真正安全的退出，得靠 context.Context 主动控制生命周期。

panic 是异常路径，context.Cancel 是正常路径 —— 两者要分开处理，不能互相替代。

• goroutine 启动时必须接收 ctx context.Context 参数，并在关键阻塞点（如 ch 、<code>、<code>http.Do）检查 ctx.Done()
• 不要用 select { case 包裹整个 goroutine —— 这样 panic 发生时还是逃不出去
• 推荐结构：外层 defer recover，内层 select 处理 ctx 和业务 channel，panic 和 cancel 都导向 cleanup
• 性能影响：ctx.Done() 是无锁 channel 操作，开销极小；但频繁 select 多个 channel 会略微增加调度负担，合理合并条件即可

log.Fatal / os.Exit 在 goroutine 里会杀掉整个进程

这是个隐蔽但致命的坑：有人在 goroutine 里写 log.Fatal("xxx")，以为只是“记录并退出当前 goroutine”，结果整个程序退出了。

因为 log.Fatal 底层调的是 os.Exit(1)，它不区分 goroutine，直接终止进程。

• 错误写法：go func() { if err != nil { log.Fatal(err) } }() —— 一个 goroutine 错误，全服务崩
• 正确替代：log.Printf("error: %v", err) + return，或封装为带 error 返回的函数，由调用方决定是否终止
• 如果你真需要“某类错误必须终止服务”，应该让错误透传回 main 函数，由 main 统一调用 os.Exit
• 兼容性注意：所有标准库的 log.Fatal*、log.Panic*、fmt.Fprint*ln(os.Stderr, ...); os.Exit 行为一致，别心存侥幸

真正难的不是写 recover，而是判断哪些 goroutine 值得加、哪些该用 context 控制、哪些压根不该起。很多人加了一堆 defer recover，却忘了 goroutine 本身是不是必要 —— 很多“并发”其实只是顺序逻辑套了 go 关键字而已。