Go context 怎样读取取消原因而不是只看 Done

只看 ctx.Done() 只能知道“这项工作结束了”，看 ctx.Err() 通常也只能得到 context.Canceled 或 context.DeadlineExceeded。如果调用方还要区分“用户主动取消”“下游返回业务错误”和“上游超时”，应在创建子上下文时使用 context.WithCancelCause，取消时传入错误，接收端再用 context.Cause(ctx) 读取原因。

先把取消通知和取消原因分开

Go 的 Context 取消仍然依靠关闭 Done 通道完成广播。Cause 并没有改变这个模型，它只为同一次取消增加了一条诊断信息。这样既能保持已有函数对 ctx.Done() 的兼容，又能让边界层知道失败来自哪里。

用 WithCancelCause 保存真正的失败原因

取消函数的参数应该描述触发取消的事件，而不是再包装一层泛化错误。下面的例子模拟一个上游任务发现后端不可用，主动终止子任务；子任务只负责退出，调用方在收尾时读取具体原因。

package main

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

var errBackendUnavailable = errors.New("backend unavailable")

func worker(ctx context.Context) error {
    select {
    case 

这里的 ctx.Err() 仍然是 context.Canceled，而 context.Cause(ctx) 是 errBackendUnavailable。日志可以据此把“任务被取消”和“任务因后端不可用而取消”分别统计。

接收端按 Err 与 Cause 做分层判断

建议先判断 Err，再按 Cause 选择处理策略。不要直接把 Cause 当成所有控制逻辑的唯一依据：父上下文可能先超时，子上下文随后才收到通知，此时原因属于上游生命周期。

func classify(ctx context.Context) string {
    if err := ctx.Err(); err != nil {
        // 先确认已经取消，再读取 Cause，避免未取消时得到 nil 而误判。
        cause := context.Cause(ctx)
        switch {
        case errors.Is(cause, errBackendUnavailable):
            return "backend-fallback"
        case errors.Is(err, context.DeadlineExceeded):
            return "timeout"
        default:
            return "canceled"
        }
    }
    return "running"
}

父子 Context 中只认第一次取消

Cause 的边界很重要：一个上下文或它的父上下文第一次取消时，原因就确定了。若父 Context 先因超时结束，子 Context 后面再调用自己的取消函数，子 Context 看到的仍可能是父级超时。反过来，子 Context 先被业务错误取消，父 Context 后续取消也不会改写子 Context 已记录的原因。

工程上可以把 WithCancelCause 放在拥有“决定权”的那一层：请求入口负责超时，业务编排层负责业务失败，底层函数只监听并返回。每一层都应继续 defer cancel(nil) 或调用普通清理函数，避免定时器、连接和后台协程滞留。

常见问题

只调用 WithCancel 还能使用 Cause 吗？

可以读取，但如果取消不是通过 Cause 函数设置，Cause(ctx) 会回退到 ctx.Err()，不会凭空产生业务错误。

cancel(nil) 会让 Cause 变成 nil 吗？

不会。对 WithCancelCause 创建的上下文，cancel(nil) 表示以 context.Canceled 作为原因；未取消前才会返回 nil。

应该把 Cause 直接返回给 API 客户端吗？

通常不应该。Cause 适合内部日志、指标和错误分类，跨边界返回前应转换为稳定的业务错误码，避免泄露内部依赖和实现细节。

实际改造时可以保留原有 Done 监听代码，只在拥有取消决策的边界替换为 WithCancelCause，然后补上 Err 与 Cause 的分层判断。这样改动小，诊断信息却能沿着同一棵 Context 树传递。