Go context deadline exceeded 怎么区分上游取消和下游超时：Cause 与 errors.Is 的判断顺序

线上接口日志里同时出现 context canceled 和 context deadline exceeded 时，先别把它们都归到“下游太慢”。前者通常表示上游主动放弃，后者表示某个提前设好的截止时间先到了；如果使用了 context.WithCancelCause，还能顺着调用链路回溯到最初触发取消的位置。判断顺序捋顺了，后续的重试逻辑、告警规则和排障结论才不会互相矛盾。

先用 errors.Is 判断错误类别，再用 context.Cause 读取取消原因；不要拿错误字符串直接做业务分支。

同一条错误日志，为什么会导向两种完全不同的处理

一个聚合接口同时请求库存和推荐服务。用户直接关闭页面的时候，HTTP请求绑定的根context会被主动取消；库存服务响应变慢时，库存子请求则可能先撞上自己设置的300毫秒截止时间。两种场景最后在上层表现出来的都是“请求没拿到预期结果”，但后续的处理方式完全不一样。

主动取消场景一般不值得重试，因为发起请求的用户已经不在等待了；下游超时则要看调用接口是否幂等、是否已经产生实际副作用，以及当前的重试预算是否充足。把两种情况混在一起处理，最常见的后果就是给已经离开的用户继续发起下游调用，或者对真正出现故障的依赖服务没有触发任何告警。

先做第一层检查：错误类别到底是什么

Go标准库提供了两个非常稳定的哨兵错误。判断的时候用 errors.Is，不要直接比较 err.Error() 的完整文本，因为中间很可能已经被包了一层下游自定义错误。

switch {
case errors.Is(err, context.Canceled):
    log.Info("request abandoned", "reason", "parent-cancel")
case errors.Is(err, context.DeadlineExceeded):
    log.Warn("request timed out", "reason", "deadline")
default:
    log.Error("request failed", "err", err)
}

这里的判断顺序不是形式上的要求，而是为了准确保留原始错误类别。业务层可以据此决定是否把请求记入超时指标，调用层再决定要不要触发降级逻辑。即使错误来自 fmt.Errorf("query inventory: %w", err)，errors.Is 仍然能穿透包装层识别出原始错误。

第二层检查：是谁先让 context 结束

只看最终抛出来的 Err()，很多时候信息还不够完整。用 WithCancelCause 创建的父context，可以把“用户离开”“服务关闭”“配额耗尽”这类信息挂载到取消动作上。

ctx, cancel := context.WithCancelCause(context.Background())
defer cancel(nil)

go func() {
    if shuttingDown() {
        cancel(errors.New("server draining"))
    }
}()

err := callDependency(ctx)
if err != nil {
    slog.Error("dependency stopped",
        "err", err,
        "cause", context.Cause(ctx),
    )
}

context.Cause(ctx) 返回的是具体的取消原因；如果context是因为到达截止时间结束，通常能拿到对应的截止时间错误。它主要用于日志补充、指标标签分类和故障快速定位，不能把它当成唯一的业务分类入口。

把父级取消和子级超时放进一个可复现实验

下面的测试函数故意保留了两个分支：一个由父级主动取消触发，一个由子级自己的截止时间触发。运行测试的时候不要只打印一行提示字符串，至少把 err、cause 和对应的分支标签一起记录下来。

func inspect(ctx context.Context, stopParent bool) string {
    child, stop := context.WithTimeout(ctx, 30*time.Millisecond)
    defer stop()

    if stopParent {
        if cancel, ok := ctx.Value(cancelKey{}).(context.CancelCauseFunc); ok {
            cancel(errors.New("client left"))
        }
    }

    

真实项目里不建议把取消函数塞进context value里；这里仅为了更清晰地展示事件触发顺序。更稳妥的做法是让持有取消函数的控制层直接调用它，再把普通context透传给下层业务函数。

修复日志与重试策略：先分类，再决定动作

日志字段建议固定为 ctx_err、ctx_cause、dependency 和 retryable。这样可以在同一张监控看板里清晰分辨“请求主动取消占比高”和“依赖超时占比高”两种异常，而不是靠人工搜索日志里的自然语言关键词排查。

• 收到 context.Canceled：直接停止后续所有工作，通常不做重试，也不把它标记为服务故障。
• 收到 context.DeadlineExceeded：记录对应依赖名和截止时间来源，再根据接口幂等性和剩余重试预算决定重试、降级或者触发告警。
• 拿到自定义Cause：把它放进单独的诊断字段，不要覆盖掉标准的错误类别标记。

一个容易遗漏的边界场景是：子context可能已经触发超时，父context随后又被取消。此时要以先发生的事件为准；如果想还原完整的事件链路，应该在每一层调用里记录自己设置的deadline和cause，而不是试图从最外层的错误字符串倒推完整时间线。

反向验证：用表格把结论锁住

测试的时候分别模拟父级主动取消和子级到期超时两种场景，先断言 errors.Is 的返回结果是否符合预期；再断言 context.Cause 是否包含预设的原因。只测单条超时路径，没法证明取消传播和错误包装的全链路逻辑都能正常工作。

常见问题

为什么不直接比较 err == context.DeadlineExceeded？

因为错误可能被下游服务或者业务中间层多次包装。errors.Is 会顺着完整错误链做判断，适合做稳定的业务分支逻辑判断。

context.Cause 能替代 ctx.Err() 吗？

不能。Err() 负责做标准错误类别判定，Cause() 负责返回更具体的取消原因，两者配合使用同时记录就好。

看到 deadline exceeded 就一定要重试吗？

不一定。先确认请求是否幂等、剩余截止时间是否还够用、下游服务是否还有剩余容量；不然盲目重试只会放大集群拥塞。

最后留一条可操作的判断顺序

先看 errors.Is(err, context.Canceled) 和 errors.Is(err, context.DeadlineExceeded)，再读 context.Cause(ctx)，最后结合依赖名、deadline来源和幂等性决定后续动作。这样处理之后，日志会清晰告诉你“谁结束了请求、为什么结束、下一步能不能重试”，而不是只留下一句模糊的超时提示。