Go context.Cause 怎样读取取消上下文的原始原因

在 Go 的取消处理里，ctx.Err() 通常只能告诉我们“已取消”还是“已超时”。如果上层还需要知道是谁主动终止、哪个业务条件触发了取消，就应该在创建上下文时使用 context.WithCancelCause 或 context.WithTimeoutCause，再用 context.Cause(ctx) 读取原始原因。

结论：Err 适合做稳定的控制分支，Cause 适合记录和传递具体原因；如果上下文是普通取消，Cause 仍会回落到 ctx.Err()。

先区分 Err 与 Cause 返回的两层信息

Context.Err 的返回集合比较稳定：未取消时是 nil，主动取消通常是 context.Canceled，截止时间到期则是 context.DeadlineExceeded。Cause 关注的是更具体的错误原因，而且在上下文尚未取消时同样返回 nil。

因此不要把二者简单替换。服务层可以继续用 errors.Is(err, context.Canceled) 判断控制语义，同时把 context.Cause(ctx) 写入日志或错误详情。

用 WithCancelCause 写入主动取消原因

主动取消要保存业务错误，关键是让取消函数接收一个 error。调用方等待 Done 关闭后，再分别读取 Err 和 Cause：

package main

import (
    "context"
    "errors"
    "fmt"
)

func main() {
    // 用可携带原因的取消器创建子上下文。
    ctx, cancel := context.WithCancelCause(context.Background())

    // 业务校验失败时，把具体错误写入取消原因。
    cause := errors.New("配置版本不支持")
    cancel(cause)

    // Done 关闭后，Err 给出通用状态，Cause 保留原始错误。
    

这里的两个输出职责不同：ctx.Err() 仍然是 context.Canceled，而 context.Cause(ctx) 才是传入的 cause。取消函数只会记录第一次生效的原因，后续再次调用不会覆盖它。

处理超时、父子上下文与普通取消

需要给“超时”附加固定原因时，可以使用 WithTimeoutCause。它只会在截止时间真正到期时设置原因；如果调用返回的普通取消函数提前结束上下文，不会用这个超时原因覆盖提前取消。

ctx, cancel := context.WithTimeoutCause(
    context.Background(),
    200*time.Millisecond,
    errors.New("上游服务超时"), // 仅截止时间到期时作为 Cause
)
defer cancel() // 无论是否超时都释放计时器资源

select {
case 

父上下文先取消时，子上下文通常会继承父上下文的取消原因；子上下文先通过自己的 CancelCauseFunc 取消，则可以保留自己的原因。若使用的是普通 WithCancel，没有额外原因可记录，Cause(ctx) 会与 ctx.Err() 返回同一个取消错误。

把 Cause 接入实际错误处理

推荐把 Err 用在程序控制路径，把 Cause 用在诊断信息和上层解释。比如一个数据库查询函数收到取消时，不要只把任意原因直接变成重试信号：

func load(ctx context.Context) error {
    if err := query(ctx); err != nil {
        // 下游可能先返回自己的错误，先保留真正的查询错误。
        return err
    }
    if err := ctx.Err(); err != nil {
        // 控制分支按标准取消错误判断，避免依赖错误文本。
        return fmt.Errorf("request stopped: %w; cause=%v", err, context.Cause(ctx))
    }
    return nil
}

落地时记住三点：先等待或确认取消状态再读取原因；用 errors.Is 判断取消类别，不比较错误字符串；没有使用 Cause 取消器的旧代码不需要强行改造，读取到的就是与 Err 一致的通用错误。

相关问题

上下文没有取消时 Cause 返回什么？

返回 nil。只有上下文或它的父级已经取消后，Cause 才有可读取的错误。

Cause 能替代 ctx.Err 吗？

不能完全替代。Err 的取消类别适合稳定分支，Cause 的具体错误适合诊断和业务说明，两者应按职责同时保留。

小结：创建上下文时决定是否携带原因，取消发生后用 Err 判断通用状态、用 Cause 读取更具体的信息；父子传播和第一次取消规则则决定最终拿到哪一个错误。