Go协程错误处理全攻略

“纵有疾风来，人生不言弃”，这句话送给正在学习Golang的朋友们，也希望在阅读本文《Go语言协程错误处理技巧》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新Golang相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

协程中 panic 无法被外层 defer 捕获，必须在每个 goroutine 内部用 defer/recover 处理；推荐通过 channel 传递 error、用 context 控制超时与取消、用 errgroup 统一管理错误。

协程中 panic 无法被外层 defer 捕获

Go 的 goroutine 是独立的执行流，其内部发生的 panic 不会传播到启动它的主协程或其他协程。这意味着你在主函数里用 defer/recover 完全捕获不到子协程里的崩溃。

• 典型现象：panic: runtime error: index out of range 直接终止整个程序，哪怕外层有 recover()
• 根本原因：每个 goroutine 有自己的调用栈和 panic 栈，recover() 只对当前 goroutine 有效
• 正确做法：必须在每个可能出错的协程内部做 defer/recover

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("goroutine panic: %v", r)
        }
    }()
    // 可能 panic 的逻辑，比如 slice 越界、nil 指针解引用
    _ = []int{1}[5]
}()

使用 channel 配合 error 类型传递错误结果

当协程需要返回计算结果或错误时，推荐用 chan error 或带 error 字段的结构体通道（如 chan Result），避免靠日志“猜”哪里失败了。

• 适用场景：多个协程并行请求 API、批量处理文件、数据库批量插入
• 注意点：channel 必须有缓冲或确保接收方已就绪，否则协程可能阻塞甚至泄露
• 不要用全局变量或共享 map 存错误 —— 竞态风险高，且难以追踪来源

type Result struct {
    Data string
    Err  error
}
<p>ch := make(chan Result, 10) // 缓冲足够容纳所有结果
go func() {
defer close(ch)
for _, url := range urls {
resp, err := http.Get(url)
ch <- Result{Data: url, Err: err}
}
}()</p><p>for r := range ch {
if r.Err != nil {
log.Printf("failed on %s: %v", r.Data, r.Err)
}
}</p>

context.WithCancel + select 处理超时与主动取消时的错误清理

协程不是孤立存在的，常需响应上下文取消（如 HTTP 请求超时、用户中断）。若只依赖 channel 接收，可能错过取消信号，导致资源泄漏或重复错误。

• select 中必须包含 <-ctx.Done() 分支，并检查 ctx.Err() 判断是超时还是主动取消
• 在 ctx.Done() 分支里做清理（关闭文件、释放锁、通知下游），而不是直接 return
• 别在协程里反复调用 ctx.Err() —— 应该用 select 等待它，否则浪费 CPU

ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
<p>go func(ctx context.Context) {
defer func() {
if r := recover(); r != nil {
log.Printf("panic in worker: %v", r)
}
}()
select {
case <-time.After(5 * time.Second):
log.Println("work done")
case <-ctx.Done():
log.Printf("canceled: %v", ctx.Err()) // 输出 context deadline exceeded 或 canceled
// 这里可以关闭连接、释放内存等
}
}(ctx)</p>

error group（errgroup）统一等待与错误聚合

标准库没有内置 error group，但 golang.org/x/sync/errgroup 是事实标准。它解决的是「等所有协程结束，只要一个出错就提前返回」的问题，比手写 sync.WaitGroup + 全局 error 变量更安全、更清晰。

• 默认行为：第一个非 nil 错误触发 Wait() 返回，其余协程仍运行（除非你传入 ctx 控制生命周期）
• 若要“任意错误即停止所有”，必须配合 context.WithCancel，并在每个协程中监听 ctx.Done()
• 注意：eg.Go() 启动的函数签名必须是 func() error，不能直接传带参数的闭包（需显式捕获）

g, ctx := errgroup.WithContext(ctx)
for _, task := range tasks {
    task := task // 避免循环变量复用
    g.Go(func() error {
        select {
        case <p>实际项目里最易忽略的是 panic 恢复的粒度 —— 很多人只在顶层加 recover，却忘了每个新起的 goroutine 都是新的 panic 边界。还有就是把 error 当日志打完就丢，没走 channel 或 errgroup 回传，导致调用方完全不知道协程是否成功。</p><p>今天关于《Go协程错误处理全攻略》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！</p>