goroutine 中 panic 无法被外部 defer 捕获，必须在每个可能 panic 的 goroutine 内部用 defer + recover 处理；error 应通过带缓冲的 chan error 传递，避免共享变量竞态。
goroutine 中 panic 无法被外部 defer 捕获
Go 的 goroutine 是独立的执行流，主 goroutine 的 defer 对其他 goroutine 内部的 panic 完全无效。一旦子 goroutine panic 且未处理，程序会直接崩溃（除非启用了 recover）。
- 错误写法：
go func() { panic("oops") }()—— 主协程继续运行，但子协程 panic 后进程退出 - 正确做法：每个可能 panic 的 goroutine 内部必须配对使用
defer+recover - 注意：
recover()只在defer函数中调用才有效，且仅能捕获当前 goroutine 的 panic
error 通道传递比全局变量或闭包更可靠
多个 goroutine 并发执行时，共享变量（如 err 指针或闭包捕获的变量）容易因竞态导致覆盖或丢失错误。用 chan error 显式传递是 Go 推荐模式。
- 声明通道：
errCh := make(chan error, 1)（带缓冲避免阻塞） - 启动 goroutine：
go func() { errCh - 接收错误：
if err := - 若需收集多个错误，可用
for i := 0; i
context.WithTimeout 配合 select 实现超时与错误统一处理
异步操作常需超时控制，而 select 能自然聚合 channel 接收和 context 取消信号，避免手动轮询或额外 goroutine。
- 典型结构：
select { case err := -
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，记得在 goroutine 结束后调用cancel()（或用defer cancel()） - 注意：
ctx.Err()在超时后为context.DeadlineExceeded，不是普通error值，需显式判断
第三方库 errgroup 更适合多任务聚合错误
当需要并发执行多个函数并等待全部完成、同时收集首个或全部错误时，golang.org/x/sync/errgroup 比手写 channel 更简洁安全。
立即学习“go语言免费学习笔记（深入）”；
- 用法：
g, ctx := errgroup.WithContext(ctx)，然后g.Go(func() error { ... }) -
g.Wait()返回第一个非 nil 错误；若要收集所有错误，需自行改用sync.WaitGroup+chan error - 它自动继承 context 取消行为，无需手动监听
ctx.Done() - 注意：如果某个 goroutine panic，
errgroup不会捕获，仍需内部加recover
实际并发错误处理最易忽略的是 panic 传播边界和 channel 缓冲大小——前者导致崩溃无声，后者导致 goroutine 永久阻塞。
