context.Context 不应用于传递 Error，因其仅负责取消和超时控制；error 必须显式返回以保持可追踪性、符合 go 惯用法，并与标准库兼容。
Go 的 context.Context 本身不设计用来“传递错误”，它只提供取消信号和超时控制；想靠 context.WithValue 塞一个 error 进去再取出来，属于误用，且会破坏错误链路的可追踪性。
为什么不能用 context.WithValue 传 error
Context 的 value 是为传递请求范围的、不可变的元数据（比如用户 ID、trace ID）而设的，不是错误传播通道。用它传 error 会导致：
- 调用方无法用
errors.Is或errors.As判断错误类型，因为 error 被藏在 context 里，脱离了返回值契约 - 中间件或中间函数可能无意中丢弃 context（比如没透传），error 就静默消失了
- 违反 Go “error is value” 的惯用法：错误应该显式返回，而不是隐式藏在上下文里
- 与
http.Handler、database/sql等标准库模式冲突——它们都靠返回 error 来通知失败
正确做法：error 仍走 return，context 只管 cancel/timeout
把 context 和 error 当作两个正交职责：context 控制生命周期，error 报告结果。典型组合用法如下：
func fetchUser(ctx context.Context, id string) (*User, error) { // 使用带超时的 context 发起 HTTP 请求 ctx, cancel := context.WithTimeout(ctx, 5*time.Second) defer cancel() req, err := http.NewRequestWithContext(ctx, "GET", "/user/"+id, nil) if err != nil { return nil, err // 错误直接返回 } resp, err := http.DefaultClient.Do(req) if err != nil { // 注意：这里可能是 context.Canceled 或 context.DeadlineExceeded if errors.Is(err, context.Canceled) || errors.Is(err, context.DeadlineExceeded) { return nil, fmt.Errorf("fetch user timeout or canceled: %w", err) } return nil, fmt.Errorf("http request failed: %w", err) } defer resp.Body.Close() if resp.StatusCode != http.StatusOK { return nil, fmt.Errorf("unexpected status %d", resp.StatusCode) } // ... 解析 body }关键点：
立即学习“go语言免费学习笔记（深入）”；
- 所有函数签名保持
func(..., context.Context) (T, error)形式 - 当底层操作因 context 被取消而失败时，用
errors.Is(err, context.Canceled)显式识别并包装，不掩盖原始原因 - 不要在 context 里存 error，但可以存
errgroup.Group或自定义状态标记（如ctx = context.WithValue(ctx, keyIsRetrying, true)），仅限辅助逻辑判断
需要跨多层“携带错误上下文”？用 fmt.Errorf 包装 + %w
当错误需要附加上下文信息（比如哪一层出错、参数值、重试次数），应通过错误包装实现，而非塞进 context：
// 错误发生时，立即包装 if err != nil { return nil, fmt.Errorf("in validateEmail(%q): %w", email, err) } // 多层调用后，仍可追溯原始 error _, err := fetchUser(ctx, "u123") if err != nil { if errors.Is(err, sql.ErrNoRows) { log.Println("user not found") } }这样做的好处：
- 错误链完整，
errors.Unwrap和errors.Is依然有效 - 调试时打印 error 会自然带上各层上下文，无需手动从 context 里捞
- 不依赖任何 runtime 状态，测试更可靠
真正容易被忽略的是：很多人试图让 context 承担错误传播职责，其实是混淆了“控制流中断”（cancel）和“业务逻辑失败”（error）——前者是 context 的本职，后者必须由函数签名明示。强行混用会让错误处理变得隐晦且难以测试。