当前位置：首页 > 文章列表 > Golang > Go教程 > Golang错误处理与并发技巧

Golang错误处理与并发技巧

2026-02-19 09:09:42 0浏览收藏

Golang中goroutine内的panic不会直接崩溃主程序，但若未用recover捕获，会导致该goroutine静默终止并输出堆栈日志，而调用方对此一无所知——这种“看似正常实则失联”的错误传播极易引发隐蔽bug；真正健壮的并发错误处理需主动规避goroutine内panic，改用显式error返回，并通过带缓冲的channel（如chan error）安全、可靠地将错误回传主线程，杜绝竞态与信息丢失，让并发逻辑既高效又可控。

Golang错误处理与并发_在Goroutine中捕获与传递错误

goroutine 里 panic 会直接崩溃主程序吗

不会自动崩溃，但也不会被上层捕获——panic 在 goroutine 内部发生时，若没用 recover 拦截，会终止该 goroutine，并把 panic 信息打印到 stderr（带 stack trace），主程序继续运行。这是常见误解的根源：以为“没崩”就等于“安全”，其实错误已被吞掉，调用方完全不知情。

典型现象：go func() { panic("oops") }() 执行后程序看似正常，但日志里突然冒出一行 panic trace，上游逻辑却收不到任何失败信号。

必须显式处理：要么在 goroutine 内用 defer + recover 捕获并转为错误值
要么避免在 goroutine 里 panic，改用返回 error
标准库如 http.Server 的 handler 就是后者——它要求 handler 函数自己处理错误，不依赖 panic

怎么把 goroutine 的 error 传回主线程

靠 channel 最直接：定义一个 chan error，goroutine 执行完把结果（或错误）发进去，主线程用 select 或 recv 等待。别用全局变量或闭包赋值——竞态风险高，且无法判断是否已写入。

示例：

errCh := make(chan error, 1)
go func() {
    errCh

channel 容量至少为 1，防止 goroutine 因发送阻塞而卡死
如果可能有多个 goroutine，用带缓冲的 channel + for range，或用 sync.WaitGroup 配合单个 error 变量（需加锁）
注意超时：用 select 包一层，避免无限等待

使用 errgroup.Group 时 error 被覆盖怎么办

errgroup.Group 的 Go 方法只保留第一个非 nil 错误，后续错误全丢弃。这在并发请求场景下很危险——比如调用 3 个下游服务，第二个失败了，第三个也失败了，但你只能看到第二个的错误。

原因在于它的内部实现是原子写入首个错误，不聚合。

如果需要所有错误，别用 errgroup，改用 sync.WaitGroup + 切片收集 error
或者封装一层：每个 goroutine 把 error 发到统一的 chan error，主线程收集全部再判断
注意 errgroup.WithContext 的 cancel 行为：任一子任务出错，context 会被 cancel，其他还在跑的 goroutine 可能提前退出——这不是错误覆盖，是主动中止

defer + recover 在 goroutine 中为什么有时不生效

最常见原因是 recover 放错了位置：它必须和 panic 在同一个 goroutine，且必须在 defer 函数里调用。如果 recover 写在另一个函数里、或 defer 没包住 panic 路径，就完全无效。

错误写法：

go func() {
    defer safeRecover() // safeRecover 里写了 recover()，但没 return，也没输出
    panic("boom")
}()

正确写法：

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("recovered in goroutine: %v", r)
        }
    }()
    panic("boom")
}()