Go协程池错误处理核心是隔离失败、不中断其他任务、可追溯归因：任务需自行捕获panic并返回error，使用带context的I/O操作，结果通过带id的channel收集，并记录含task_id和堆栈的日志。
在 Go 中使用协程池（goroutine pool）时，错误处理的核心不是“阻止 panic”，而是“隔离失败、不中断其他任务、可追溯归因”。关键在于：每个任务独立捕获错误、池本身不崩溃、结果能明确区分成功与失败。
任务内部主动捕获并返回错误
协程池中的每个任务应自行处理可能的 panic 或业务错误，并统一通过返回值暴露。不要依赖 defer+recover 在池启动层兜底——那会掩盖问题源头，且无法把错误关联到具体任务。
- 定义任务函数签名如 func() (result interface{}, err error)，而非无返回的
func() - 在任务体内用
defer func(){...}()捕获 panic，并转为 error 返回 - 网络调用、JSON 解析、数据库操作等易错点，必须显式检查 err 并提前 return
池执行器需支持带上下文的任务提交与结果收集
避免裸写 go fn()。使用封装好的池（如 ants）或自建池时，确保提交接口支持接收 error，并提供同步等待或异步回调机制。
- 提交任务后获取唯一 taskID 或 channel，用于后续结果匹配
- 推荐用 chan struct{ result interface{}; err error; id string } 收集结果，避免 map 竞态
- 若用 ants，搭配
pool.SubmitWithTimeout或自定义 callback，防止任务无限阻塞
超时与取消必须由任务自身响应
协程池无法强制终止 goroutine。超时控制必须靠任务主动检查 context.Done() 或设置 deadline。
- 任务入参应包含
context.Context，所有 I/O 操作（http.Do、db.QueryContext、time.Sleep）都用带 context 的版本 - 避免在任务中起新的 goroutine 却不传 context，否则 timeout 后仍可能运行
- 池层面可设置最大执行时间，但仅用于标记“已超时”，真正退出靠任务内 context 判断
错误日志要带任务标识和堆栈片段
单纯打印 err.Error() 不足以定位问题。需记录任务 ID、输入参数摘要、发生时间，以及 panic 时的 stack trace。
- 用
debug.PrintStack()或runtime.Stack(buf, false)获取当前 goroutine 堆栈 - 日志字段示例：task_id=abc123 method=FetchUser user_id=789 error="timeout: context deadline exceeded" stack="main.fetchData at api.go:42"
- 敏感参数（如密码、token）需脱敏，避免日志泄露
