必须用带缓冲的chan error回传可预期错误，并在每个goroutine内用defer+recover捕获panic转为error发送；chan容量至少为1，避免阻塞导致泄漏。
Go 中 goroutine 的错误无法通过 return 返回给调用者，必须显式传递——最安全、最符合 Go 习惯的方式是用带缓冲的 chan error 回传业务错误；而对不可预期的 panic，则必须在每个 goroutine 内部用 defer + recover 捕获并转为 error 发送，二者缺一不可。
用 chan error 传递可预期错误（推荐用于 HTTP 请求、文件读写等）
这是处理「本该出错、且能提前判断」场景的标准做法
。主 goroutine 启动子协程时，额外提供一个带缓冲的 error channel，子协程执行完后把 error（或 nil）发进去。
- channel 必须带缓冲，容量至少为 1（单任务）或 ≥ 并发数（多任务），否则发送时可能永久阻塞，导致 goroutine 泄漏
- 不要在 goroutine 里直接
errCh 后继续执行——应搭配defer或立即发送后退出，避免后续逻辑干扰 - 主 goroutine 推荐用
select等待，而非无条件，以防其他路径已提前退出
errCh := make(chan error, 1)
go func() {
defer func() {
if r := recover(); r != nil {
errCh <- fmt.Errorf("panic: %v", r)
}
}()
errCh <- doSomething() // 业务函数返回 error
}()
select {
case err := <-errCh:
if err != nil {
log.Printf("task failed: %v", err)
}
case <-time.After(5 * time.Second):
log.Println("timeout")
}
用 defer + recover 拦截 panic（必须用于网络 handler、定时任务等长期运行协程）
goroutine 内的 panic 不会传播到外层，不 recover 就会静默退出，可能造成连接未关闭、资源未释放、监控失察等问题。recover 只在 defer 函数中有效，且必须直接调用。
-
recover()返回interface{}，需类型断言转为error才能统一处理 - recover 后不应“假装无事发生”继续执行高风险逻辑，只做日志、清理、发错、退出
- 务必配合
runtime.Stack记录完整堆栈，否则仅凭 panic 值很难定位问题
go func() {
defer func() {
if r := recover(); r != nil {
var buf [4096]byte
n := runtime.Stack(buf[:], false)
err := fmt.Errorf("panic recovered: %v\nstack:\n%s", r, buf[:n])
errCh <- err // 发给主 goroutine 统一处理
}
}()
http.ListenAndServe(":8080", nil) // 可能因空指针、配置错误 panic
}()多个 goroutine 错误收集：WaitGroup + 缓冲 channel + context 协同
并发执行一批任务（如批量调用下游 API），既要等全部完成，又要拿到所有错误，还希望某一个失败就快速取消其余——这时不能只靠 channel，得组合使用。
-
sync.WaitGroup保证主 goroutine 不提前退出 -
chan error缓冲大小设为任务总数，避免任一 goroutine 在发送时卡住 -
context.WithCancel实现“一错即停”，出错时调用cancel()，其余任务通过ctx.Done()主动退出
ctx, cancel := context.WithCancel(context.Background()) errCh := make(chan error, len(tasks)) var wg sync.WaitGroupfor _, task := range tasks { wg.Add(1) go func(t Task) { defer wg.Done() if err := t.Run(ctx); err != nil { errCh <- err cancel() // 触发全局取消 } }(task) }
go func() { wg.Wait() close(errCh) }()
for err := range errCh { log.Printf("task error: %v", err) }
真正容易被忽略的是：**recover 不是 error 处理的替代品，而是兜底保险；而 error channel 不是 recover 的补充，而是正向流程的必经之路**。两者常共存于同一个 goroutine 中——先用 recover 拦住崩溃，再把结果（无论 panic 还是业务 error）走同一通道发出。漏掉任何一环，都可能让错误消失在日志之外。
