17370845950

Go中goroutine panic必须在内部用defer+recover捕获，recover仅在defer函数内有效；可预期错误应通过error channel传递，不可预期崩溃才用recover兜底并记录堆栈、清理后退出。

Go 中的 goroutine 一旦发生未捕获的 panic，会直接终止该协程，并且不会传播到主 goroutine，但若没做任何处理，panic 信息会打印到标准错误、程序可能看似“静默失败”，严重时还会引发资源泄漏或服务不可用。关键不是“能不能捕获”，而是必须在每个可能出错的 goroutine 内部主动设防。

用 defer + recover 捕获 panic

这是应对未知崩溃（比如空指针、越界、向已关闭 channel 发送数据）的唯一可靠方式。recover 只在当前 goroutine 的 defer 函数中有效，离开 defer 就失效。

• recover 必须写在 defer 函数里，且要直接调用（不能包在另一个函数里再调）
• 建议统一记录 panic 值 + 堆栈，方便排查：用 runtime.Stack 获取完整调用链
• 不要在 recover 后继续执行高风险逻辑，通常只做日志、告警、清理，然后退出

用 error channel 传递业务错误

对于可预期的错误（如网络超时、校验失败、数据库查不到），应避免 panic，改用 error 类型 + channel 回传。这是 Go 并发错误处理的推荐模式。

• 创建带缓冲的 error channel（容量 ≥ goroutine 数量），防止发送阻塞导致 goroutine 卡住
• 主 goroutine 通过 range 或 select 接收错误，配合 sync.WaitGroup 等待全部完成
• 多个任务中只要一个失败就要中断其余？那就结合 context.WithCancel，出错时调用 cancel()

封装安全启动函数

重复写 defer+recover 很繁琐，可以抽象成工具函数，让并发更健壮、更一致。

• 定义 goSafe(func())，内部自动包裹 recover 日志逻辑
• 可扩展支持传入 logger、trace ID、超时控制等上下文信息
• HTTP handler、定时任务、消息消费等入口处默认用 goSafe 启动子协程

别踩这些坑

很多 goroutine 错误问题其实源于设计疏忽，而不是语法不会用。

• 主 goroutine 的 defer 永远捕获不到子 goroutine 的 panic —— 这是常见误解
• 向已关闭的 channel 发送数据会 panic，读已关闭 channel 是安全的（返回零值+false）
• 不要用 recover 替代 error 处理：正常业务流程出错就该返回 error，不是抛 panic
• recover 后不加日志、不释放资源、也不退出，容易掩盖问题并引发状态不一致

基本上就这些。核心就两条：可预期的错走 error channel，不可预期的崩靠 defer+recover 守住底线。两者不冲突，常一起用。