context.WithCancel不传递业务错误，只能返回固定错误；需通过函数返回值显式传递error，配合context控制生命周期。
context.WithCancel 本身不传递错误，需要手动封装
Go 的 context.Context 接口不包含错误字段，context.WithCancel、context.WithTimeout 等函数返回的 context 也只提供 Done() 通道和 Err() 方法（仅在取消/超时后返回预设错误，如 context.Canceled 或 context.DeadlineExceeded）。它**无法承载业务错误或中间过程错误**。
常见误用是以为调用 cancel() 后，下游能通过 ctx.Err() 拿到自定义错误，实际只能得到 context.Canceled —— 这个值是固定的，不可替换。
若需传递具体错误，必须额外配合其他机制：
- 用
chan error单独传递，与 context 配合监听 - 在函数返回值中显式返回 error（最常用、最符合 Go 习惯）
- 用
sync.Once+ 全局 error 变量（仅限极简调试场景，不推荐生产）
使用 context.Value 传 error 是反模式
context.WithValue 适合传请求范围的元数据（如用户 ID、trace ID），**不适合传 error**。原因很直接：
立即学习“go语言免费学习笔记（深入）”；
- 类型断言失败时 panic 风险高：
err, ok := ctx.Value(errKey).(error)，一旦没存或类型不对，ok为 false，但容易被忽略 - 违反错误处理的显式性原则：Go 强调 error 必须被声明、返回、检查；藏在 context 里等于绕过编译检查
- 多个 goroutine 并发写入同一 key 会竞态，
context.Value是只读的，无法安全更新
你看到的某些 demo 用 context.WithValue(ctx, errKey, err)，基本是教学简化或临时调试写法，上线前务必重构掉。
推荐做法：error 作为函数返回值 + context 控制生命周期
标准模式是让业务函数同时接收 context.Context 并返回 error，由调用方统一判断 context 是否已取消，再决定是否忽略业务 error：
func doWork(ctx context.Context) error {
select {
case <-ctx.Done():
return ctx.Err() // 返回 context.Canceled 或 context.DeadlineExceeded
default:
}
// 实际工作
if err := someIOOperation(); err != nil {
return err // 返回具体业务错误，比如 io.EOF、sql.ErrNoRows
}
return nil
}
// 调用方
if err := doWork(ctx); err != nil {
if errors.Is(err, context.Canceled) || errors.Is(err, context.DeadlineExceeded) {
// 上游已取消，可跳过日志或降级
return
}
// 真正需要处理的业务错误
log.Error(err)
}
这种组合清晰分离了「控制流中断」（context）和「业务异常」（error），也是 net/http、database/sql 等标准库的实际用法。
需要跨 goroutine 传播错误？用 errgroup.Group
当启动多个子 goroutine 并希望任一出错就快速取消其余任务、同时拿到首个错误时，golang.org/x/sync/errgroup 是最佳选择——它内部用 context.WithCancel 管理生命周期，又把 error 作为返回值暴露出来：
g, ctx := errgroup.WithContext(parentCtx)
for i := range tasks {
i := i
g.Go(func() error {
select {
case <-ctx.Done():
return ctx.Err()
default:
}
return processTask(tasks[i])
})
}
if err := g.Wait(); err != nil {
// err 是第一个非 context 相关错误，或 context.Err()（如果所有子任务都因取消退出）
}
注意：errgroup.Group 的 Wait() 返回 error 是“首个非 nil 错误”，不是所有错误的集合。需要收集全部错误，请用 sync.WaitGroup + sync.Mutex 手动聚合，但多数场景不需要。
真正难的不是怎么传 error，而是想清楚：这个错误该由谁处理、是否影响其他分支、要不要重试、是否要暴露给调用方——context 只负责“喊停”，error 才负责“说清为什么停不住”。
