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
}
关键点：
