关键在于必须显式透传 context.Context 到每个阻塞调用点，因为错误包装不传递超时、取消等运行时状态；忽略 ctx 会导致上下文生命周期截断，超时逻辑失效。
Go 1.20+ 的 errors.Join 和 fmt.Errorf 带 %w 动词已能较好支持错误链，但真正决定上下文是否“可传递、可诊断、不丢失”的关键，是调用链中每个环节是否主动保留并注入 context.Context，而非依赖错误本身携带上下文。
为什么不能只靠 fmt.Errorf("xxx: %w", err) 传递上下文
错误包装（wrapping）只传递错误语义和原始堆栈，不传递 context.Context 中的超时、取消信号、值（ctx.Value()）、deadline 等运行时状态。一旦某个函数忽略传入的 ctx，后续所有基于该 ctx 的控制（如自动 cancel、timeout 检查）就彻底失效。
- 常见错误现象：
http.Handler中调用了无 ctx 的数据库查询，导致整个请求无法被 timeout 中断 - 典型场景：gRPC server 方法签名含
context.Context，但内部调用的工具函数硬编码使用全局 client（无 ctx） - 后果：上下文生命周期被截断，
ctx.Err()在下游永远为nil，超时逻辑形同虚设
必须显式透传 context.Context 到每个阻塞调用点
不是“加个 ctx 参数”就够了，而是每个可能阻塞或需响应取消的操作，都必须接受并使用它——包括 HTTP client、DB query、channel receive、time.Sleep 等。
-
http.Client.Do(req.WithContext(ctx))：必须用WithContext构造新 request，原req不带 ctx -
db.QueryContext(ctx, ...)或tx.QueryRowContext(ctx, ...)：标准库database/sql提供了 Context 版本，别用老版Query select { case ：channel 操作必须配合 <code>ctx.Done()做退出判断- 自定义函数必须声明
func DoSomething(ctx context.Context, ...)，且内部所有下游调用都继续透传
如何把上下文信息注入错误以便调试
错误本身不保存 ctx，但你可以把 ctx 中的关键可观测字段（如 trace ID、用户 ID、请求路径）提取出来，作为结构化字段附加到错误中。
立即学习“go语言免费学习笔记（深入）”；
- 推荐方式：用
fmt.Errorf("failed to process order %s: %w", orderID, err)显式拼入业务标识 - 更健壮做法：定义自定义错误类型，嵌入
error并携带字段：type ContextualError struct { Err error TraceID string UserID string } func (e *ContextualError) Error() string { return fmt.Sprintf("trace=%s user=%s: %v", e.TraceID, e.UserID, e.Err) } - 避免滥用
ctx.Value()：不要在错误里存ctx.Value("trace")，因为该值在 error 创建后可能已被回收或变更；应在调用点立即提取并固化
检查上下文是否真的生效的两个硬指标
仅看代码有没有 ctx 参数没用。验证是否真正生效，得盯住两个信号：
- 调用链最深处是否调用了
ctx.Err() != nil的判断？例如：if errors.Is(ctx.Err(), context.DeadlineExceeded) { ... } - 当父 ctx 被 cancel 后，整个调用链是否在合理时间内（毫秒级）全部退出？用
pprof或日志打点确认各层耗时是否同步骤降 - 特别注意 goroutine 泄漏：启动 goroutine 时若忘了传
ctx或未监听ctx.Done()，会导致协程永久挂起
上下文不是装饰品，是 Go 并发控制的主干。错误可以包装，但 context 必须像呼吸一样自然贯穿每一层调用——漏掉任意一环，整条链就失去响应性。最常被忽略的，是第三方库调用点是否真用了 Context 版本 API，而不是假装传了 ctx 却调用无 ctx 的旧方法。
