Go语言goroutine panic传播_Golang子协程崩溃处理策略-Golang-PHP中文网

子协程 panic 不会传播但会导致进程崩溃，必须在每个 goroutine 内部用 defer+recover 捕获；safego 需类型判断 panic 值并打印堆栈；errgroup.group 不自动 recover，须手动包装；chan error 需合理设置缓冲并及时关闭。

go语言goroutine panic传播_golang子协程崩溃处理策略

子协程里的 panic 不会自动传播到主协程，但会导致整个进程退出——这不是“静默失败”，而是“看似运行中、实则已崩溃”的陷阱。

主协程的 defer 对子协程完全无效，recover() 只能捕获当前 goroutine 的 panic。常见错误是只在 main() 里加一层 defer，结果子协程一 panic 还是直接退出进程。

recover() 必须出现在触发 panic 的同一个 goroutine 中，且必须在 defer 函数体内调用
如果 goroutine 启动后没做 defer + recover，哪怕只漏一个，就可能让服务在半夜挂掉
注意：空的 recover() 调用（比如写在 go func() { recover(); }()）没用，它必须在 defer 里，且 panic 发生在该 defer 所在函数栈内

直接 fmt.Printf("panic: %v", r) 容易掩盖问题：接口值 r 可能是 string、error 或自定义结构体，不判断类型就打印，日志里只看到 &{...} 之类无法定位的内容。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

建议用 switch r := r.(type) 分支处理，对 error 类型调用 r.Error()，对 string 直接输出，其他类型用 fmt.Sprintf("%+v", r)
加上 debug.Stack() 获取堆栈，但注意它返回的是 []byte，需转成 string；生产环境建议限制长度（如取前2048字节），避免日志爆炸
不要在 recover 后忽略资源清理：如果 panic 前打开了文件或持有了锁，recover 后得手动 close 或 unlock，否则泄漏

errgroup.Group 本身不包含 recover 逻辑，传给 eg.Go() 的函数一旦 panic，照样导致进程退出——这是线上事故高频点。

正确做法是把业务函数先用 safeGo 包一层，再传给 eg.Go()，例如：eg.Go(func() error { safeRun(func() { ... }) })
若业务函数本身返回 error，别在 eg.Go() 外层再套 go，否则会绕过 errgroup 的错误收集机制
errgroup 的 eg.Wait() 返回的是第一个非 nil error，不代表所有 goroutine 都成功了；想确认是否全部完成，得结合 runtime.NumGoroutine() 或埋点统计

用 chan error 接收子协程错误时，不设缓冲或忘记 close，主协程就会卡死在 上，整个流程 hang 住。

必须用带缓冲的 channel：errCh := make(chan error, 1)，避免 goroutine 在发送时阻塞（尤其当主协程还没开始接收）
务必在 goroutine 结束前发一次值（哪怕是 nil），并调用 close(errCh)，否则主协程用 for range errCh 会永远等下去
不要在 goroutine 内部 recover 后吞掉 error：recover 只是拦截 panic，不代表问题已解决；该返回的 error 还是要通过 channel 传出去

最常被忽略的一点：recover 后的 goroutine 状态是“已终止”，它的堆栈、局部变量、未释放的资源（timer、channel、mutex）不会自动清理。你得自己判断是否需要重试、降级或上报监控——panic 捕获只是止损第一步，不是善后终点。