context.Cause 不是 Go 标准库提供的方法，标准 context.Context 仅含 Deadline、Done、Err、Value 四个方法，Err() 只返回 context.Canceled 或 context.DeadlineExceeded 哨兵错误，不携带取消原因。
context.Cause 是什么，为什么 Go 标准库里没有它
context.Cause 并不是 Go 标准库 context 包提供的函数或方法。从 Go 1.0 到当前最新稳定版（Go 1.23），context.Context 接口只定义了 Deadline、Done、Err 和 Value 四个方法，**不包含获取“取消原因”的能力**。你看到的 context.Cause 很可能来自第三方包（如 golang.org/x/exp/context 的旧实验分支）或某些自定义封装，但它们早已废弃或未被采纳。
标准 context.Err() 只返回两个固定值：context.Canceled 或 context.DeadlineExceeded —— 它们是哨兵错误，不携带额外上下文。这意味着：如果你需要区分「用户主动取消」和「超时取消」，或者想透传具体错误（比如 "auth token expired"），仅靠标准 context 是做不到的。
如何在不改 context 接口的前提下传递取消原因
主流做法是把原因作为 Value 注入，或用包装 error 的方式组合进取消信号。关键在于：**取消动作和原因必须由调用方显式提供，context 本身只是载体**。
- 使用
context.WithValue存储原因（适合简单字符串或预定义错误码）：ctx := context.WithValue(parent, causeKey, "user clicked stop button")
之后在下游通过ctx.Value(causeKey)读取；注意causeKey必须是可比较的全局变量（如type causeKey string），不能用字符串字面量作 key - 更推荐的方式是：用自定义 error 包装标准取消错误，例如：
type CanceledError struct { Reason string Err error } func (e *CanceledError) Error() string { return e.Reason } func (e *CanceledError) Unwrap() error { return e.Err } <p>// 创建带原因的 cancel： cancel = func() { cancelFn() select { case <-done: // 等待 Done channel 关闭（确保 Err 已就绪） default: } } // 然后在 defer 或 recover 处理中检查 err == context.Canceled 并替换为 *CanceledError - 不要依赖
context.Err()的底层实现细节（比如试图类型断言其内部结构），它在不同 Go 版本中可能变化，且标准库明确不承诺可扩展性
使用 errgroup.Group 时怎么带出取消原因
errgroup.Group（来自 golang.org/x/sync/errgroup）会自动传播第一个非-nil error，并在任意 goroutine 返回错误时取消整个 group 的 context。但它同样只暴露 ctx.Err()，不附带原因。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 若某子任务因业务逻辑失败而主动取消，应在返回前手动触发 cancel 并注入原因：
g.Go(func() error { select { case <-time.After(5 * time.Second): return errors.New("timeout in worker") default: } <pre class="brush:php;toolbar:false;">// 主动取消并标记原因 if cancelFunc != nil { cancelFunc() // 触发 context 取消 // 同时设置一个共享 error 变量（需加锁或用原子操作） atomic.StorePointer(&causePtr, unsafe.Pointer(&customErr)) } return customErr})
- 更干净的做法是：让
errgroup的 error 成为你真正的“取消原因”，即避免调用cancel()，而是直接 return 带描述的 error；errgroup.Wait()返回的就是它，无需再查 context - 如果必须用
context.CancelFunc（比如要中断阻塞系统调用），那就得配合WithValue或外部状态变量来同步原因，不能指望errgroup自动帮你提取
容易踩的坑：误以为 context.WithCancelCause 是标准 API
Go 社区曾有提案（#59675）讨论加入 context.WithCancelCause，但截至 Go 1.23 仍未合入。你可能在 GitHub issue、博客或过期文档里看到它的原型用法，例如：
ctx, cancel := context.WithCancelCause(parent)
cancel(fmt.Errorf("failed to connect: %w", io.EOF))这代码在任何正式发布的 Go 版本中都会编译失败。
目前唯一安全的路径是：接受标准 context 的限制，用组合方式（WithValue + 自定义 error 类型 + 显式 error 返回）补足缺失语义。强行依赖未落地的特性，只会导致项目后期被迫重构。
真正难的不是“怎么写”，而是决定在哪一层做原因注入 —— 是 HTTP handler 入口？还是 DB 查询封装？选错层级会让原因信息丢失或污染无关模块。
