goroutine 中不能直接 return error，因主协程不等待其结束；正确做法是通过 channel、共享变量或回调传递错误，推荐带缓冲的 channel 配合 sync.WaitGroup 和 context 控制超时与取消。
goroutine 中不能直接 return error
Go 的协程是独立执行的，go func() { ... }() 启动后立即返回，主 goroutine 不会等待它结束，更不会接收它内部的 return err。常见错误是写成这样：
go func() {
if err := doSomething(); err != nil {
return err // 编译失败：无法从无返回值函数中 return error
}
}()这类写法直接报错。真正可行的是把 error 传出去——通过 channel、共享变量（需加锁）、或回调函数。
用 channel 收集 goroutine 错误最常用
定义一个 chan error，每个 goroutine 执行完把 error 发进去；主 goroutine 用 for range 或带超时的 select 接收。注意：必须关闭 channel，否则 range 会永久阻塞。
- 多个 goroutine 共用一个
chan error，容量建议设为并发数（避免阻塞） - 即使某 goroutine 成功，也应发
nil（或跳过发送），方便统一处理 - 若使用
range，务必在所有 goroutine 结束后close(ch)；推荐用sync.WaitGroup配合
errCh := make(chan error, 5) var wg sync.WaitGroupfor i := 0; i < 5; i++ { wg.Add(1) go func(id int) { defer wg.Done() if err := processItem(id); err != nil { errCh <- err return } errCh <- nil // 显式发送 nil，便于统计 }(i) }
go func() { wg.Wait() close(errCh) }()
var errors []error for err := range errCh { if err != nil { errors = append(errors, err) } }
context.WithTimeout 配合 cancel 可主动中断错误传播
当某个 goroutine 卡住或耗时过长，仅靠 channel 等不到它的 error。这时要用 context.Context 控制生命周期，并让被调函数支持取消。
立即学习“go语言免费学习笔记（深入）”；
动态WEB网站中的PHP和MySQL详细反映实际程序的需求，仔细地探讨外部数据的验证(例如信用卡卡号的格式)、用户登录以及如何使用模板建立网页的标准外观。动态WEB网站中的PHP和MySQL的内容不仅仅是这些。书中还提到如何串联JavaScript与PHP让用户操作时更快、更方便。还有正确处理用户输入错误的方法，让网站看起来更专业。另外还引入大量来自PEAR外挂函数库的强大功能，对常用的、强大的包
-
context.WithTimeout返回的ctx和cancel必须传入 goroutine - 被调函数（如
http.Do、time.Sleep、自定义函数）需检查ctx.Err()并提前退出 - 不要忽略
ctx.Err()—— 它可能等于context.DeadlineExceeded或context.Canceled，这本身就是一种 error
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second) defer cancel()errCh := make(chan error, 1) go func() { errCh <- doWithCtx(ctx) // 内部需 select { case <-ctx.Done(): return ctx.Err() } }()
select { case err := <-errCh: if err != nil && errors.Is(err, context.DeadlineExceeded) { log.Println("operation timed out") } case <-time.After(3 * time.Second): log.Println("channel hang, but shouldn't happen if cancel works") }
recover 不该用于常规错误处理
有人试图在 goroutine 里用 defer + recover 捕获 panic 并转成 error 发到 channel。这只能兜底程序崩溃，**不能替代正常 error 返回**。
- panic 是异常场景（如空指针解引用、切片越界），不是业务错误（如“用户不存在”、“网络超时”）
- recover 无法捕获其他 goroutine 的 panic；每个 goroutine 需单独 defer
- 滥用 recover 会让错误路径模糊，掩盖真实问题
真正该做的是：确保业务逻辑用 if err != nil 显式判断，只在第三方库可能 panic 且你无法修改源码时，才在 goroutine 内加一层 recover 做防御。
实际并发错误处理的复杂点不在语法，而在责任边界是否清晰：谁负责发起、谁负责超时、谁负责重试、谁汇总错误、错误是否可重入。这些决策比选 channel 还是 WaitGroup 影响更大。
