Go context.Cause 为什么拿不到真正取消原因：WithCancelCause 的传播边界

服务在超时日志里只打印出 context canceled，但真正触发取消的可能是上游主动终止、权限校验失败，或者一个更早到达的超时信号。这里最容易误判：ctx.Err() 和 context.Cause(ctx) 本来就承担不同职责。

用 WithCancelCause 写入业务错误，用 context.Cause 读取原因；Err 只负责告诉你取消属于哪一类。原因一旦被父或子 Context 的第一次取消写入，后续取消不会覆盖它。

先分清 context.Err 与 context.Cause

WithCancelCause 的返回值看起来像普通取消函数，但它多接收一个 error。这个 error 只写入“原因”字段，不会改变 ctx.Err() 的分类结果：

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

cause := errors.New("upstream rejected request")
cancel(cause)

fmt.Println(ctx.Err())
fmt.Println(context.Cause(ctx))

上面的两行分别是 context canceled 和 upstream rejected request。因此，调用方可以用 errors.Is(ctx.Err(), context.Canceled) 判断是否取消，再用 context.Cause(ctx) 做日志、指标或错误归因。没有写入具体原因时，Cause 会退回到与 Err 相同的错误。

用第一个取消者确定父子传播结果

Cause 不是每次调用 cancel 都更新。官方定义是第一次取消 Context 或其父级的动作写入原因；如果子 Context 已经先取消，子可以保留自己的原因，父级之后取消也不会覆盖它。

排查时不要只看业务函数最后返回的 error。先问“哪一个 Context 先关闭了 Done”，再对照父子两层的 Cause。尤其在 HTTP 请求、数据库调用和后台 worker 共用父 Context 时，上游先取消会让下游拿到同一个父级原因。

让取消原因在合并或转发时保留下来

多个来源需要合成一个取消信号时，直接调用普通 cancel() 会把原因压扁成 context.Canceled。转发源 Context 的 Cause 才能保留诊断信息：

merged, cancelMerged := context.WithCancelCause(parent)
stop := context.AfterFunc(source, func() {
    cancelMerged(context.Cause(source))
})
defer func() {
    stop()
    cancelMerged(context.Canceled)
}()

这里的关键不是“把所有错误拼成一条字符串”，而是保持来源的 error 身份。若 source 没有具体原因，context.Cause(source) 会返回它自己的 Err，目标 Context 仍然能保持一致的取消语义。

用表格和日志完成边界验证

生产日志建议把分类和原因分开记录，避免下游只按字符串搜索：

一条日志如果只有 context canceled，只能说明工作被取消，不能证明是用户取消还是上游错误。检查代码时可以沿着 Done() 的监听点回看：谁持有 CancelCauseFunc，哪里把具体 error 换成了普通 CancelFunc，哪一层又重新创建了不带原因的 Context。

常见问题：为什么原因还是丢了

context.Cause 会不会替换已经写入的原因？

不会。取消已经发生后再次调用 CancelCauseFunc 不会覆盖已有原因。

ctx.Err() 能不能直接拿到业务错误？

不能。它返回取消类别；需要具体 error 时读取 context.Cause(ctx)。

WithTimeoutCause 的超时原因能被手动 cancel 改掉吗？

不能。它返回的 CancelFunc 不设置原因；超时到达时才使用创建时提供的 cause。

把 Err 当作分类，把 Cause 当作归因，再按首个取消者检查父子链路，通常就能定位“明明写了业务错误，最后只剩 context.Canceled”的真正位置。