context.Cause 为什么返回父级取消原因

context.Cause(child) 返回父级取消原因，核心规则只有一句：对这个子级来说，它自身或任一父级发生的第一次取消会固定取消原因。父级先调用 CancelCauseFunc(parentErr) 时，取消信号和 parentErr 一起传到子级；此后再调用子级的取消函数，也不能把已经记录的原因改成另一个错误。

官方文档：https://pkg.go.dev/context

取消原因从哪里进入子级

线上常见的误判是：代码先创建父级，再通过父级派生子级，因为手里拿着子级的 CancelCauseFunc，便认为子级原因一定由这把函数决定。实际上，子级有两个取消来源：调用自己的取消函数，或者父链上任意 Context 被取消。Go 标准库明确规定，父级取消会同时取消所有派生 Context。

WithCancelCause 只是让取消动作能附带一个错误。这个错误会被 Cause 读取；如果调用 cancel(nil)，记录的原因是 context.Canceled。它没有提供“后来覆盖原因”的能力。

父级先取消时子级为什么会继承原因

下面的场景最容易复现标题中的现象。父级先写入“请求已结束”，子级随后尝试写入“局部任务失败”。由于子级在父级取消传播时已经进入取消状态，后一次调用不会改写它的 cause。

package main

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

func main() {
	parentErr := errors.New("请求已结束")
	childErr := errors.New("局部任务失败")

	parent, cancelParent := context.WithCancelCause(context.Background())
	child, cancelChild := context.WithCancelCause(parent)

	// 父级先取消，取消状态和 parentErr 会传播到 child。
	cancelParent(parentErr)
	

这里的重点不是“父级优先级更高”，而是父级先发生。官方对 CancelCauseFunc 的说明给出了对称规则：如果父级以 cause1 先取消，父级和子级都得到 cause1；如果子级以 cause2 先取消，子级保留 cause2，父级稍后取消时只影响父级自身及尚未取消的其他后代。

子级先取消时结果会反过来

把两次取消的顺序交换，就能看出 cause 不是沿父链回写的。子级取消不会取消父级，也不会把子级错误保存到父级；父级稍后仍能记录自己的原因。

func childFirst() {
	parentErr := errors.New("上游连接关闭")
	childErr := errors.New("查询结果校验失败")

	parent, cancelParent := context.WithCancelCause(context.Background())
	child, cancelChild := context.WithCancelCause(parent)

	// 子级先记录自己的业务原因，随后它的 cause 就固定下来。
	cancelChild(childErr)
	

所以排查时不要只看 Context 的层级，还要看哪一次取消先被观察到。若父级超时、客户端断开或服务停机已经先关闭了父级 Done，子任务随后返回的业务错误不能再成为该子 Context 的取消原因。业务函数自己的返回值仍可以携带那个错误，但 context.Cause(child) 不会被改写。

Err 与 Cause 各自回答什么

ctx.Err() 回答的是“这个 Context 是否因取消或截止时间而结束”，返回值限定为 context.Canceled、context.DeadlineExceeded 或 nil。context.Cause(ctx) 回答的是“造成这次取消的更具体原因是什么”。使用 WithCancelCause 传入业务错误后，Err 仍然是标准状态，Cause 才是业务错误。

var ErrQuotaReached = errors.New("并发配额已满")

func inspectCause() {
	ctx, cancel := context.WithCancelCause(context.Background())

	// 用业务错误解释为什么主动结束这项工作。
	cancel(ErrQuotaReached)
	

超时也遵循首次取消规则

WithTimeoutCause 与 WithDeadlineCause 可以在截止时间真正到达时为子级设置指定原因。但如果父级更早取消，子级先接收到的是父级原因，自己的超时原因不会覆盖它。反过来，如果子级的截止时间先到，子级保存自己的超时原因；父级之后的取消不会改写子级。

func parentWinsTimeout() {
	parentErr := errors.New("服务正在关闭")
	childTimeout := errors.New("下游查询超过三秒")

	parent, cancelParent := context.WithCancelCause(context.Background())
	child, cancelChild := context.WithTimeoutCause(parent, 3*time.Second, childTimeout)
	defer cancelChild() // 及时释放定时器等关联资源。

	// 父级在三秒截止时间之前取消，child 会继承 parentErr。
	cancelParent(parentErr)
	

还有一个容易忽略的细节：WithTimeoutCause 返回的是普通 CancelFunc，手动调用它不会写入构造时提供的超时 cause；那个 cause 只用于截止时间实际到达的情况。手动提前取消时，应把它理解为普通取消。

并发取消时不要假设谁会赢

如果两个 goroutine 几乎同时取消父级和子级，业务代码往往无法稳定预测子级最终记录哪一个原因。规范保证的是“首次取消固定 cause”，不是“子级调用在源码中写得更靠前就一定胜出”。调度、同步点和传播时机都会影响谁先完成状态变更。

因此测试应显式控制顺序：父级先取消的用例先调用父级取消函数并等待 child.Done()；子级先取消的用例先调用子级取消函数并等待其 Done，再取消父级。若生产逻辑允许并发取消，就应把多个原因都视为合法结果，或在更高层增加单一仲裁点，而不是依赖竞态决定业务语义。

什么时候用 WithoutCancel 切断继承

context.WithoutCancel(parent) 会保留父级值，但切断父级的取消、截止时间和 cause 传播。返回的 Context 没有 Deadline，Done() 为 nil，Err() 和 Cause 都返回 nil。它适合确实要脱离请求生命周期的收尾工作，但不能把它当成默认修复，因为这也会丢掉客户端断开和服务超时带来的停止信号。

func detachedChild(parent context.Context) context.Context {
	// 切断父级取消传播，但仍可读取父级携带的请求级值。
	base := context.WithoutCancel(parent)

	// 为后台工作建立新的独立超时，避免任务无限运行。
	ctx, _ := context.WithTimeoutCause(
		base,
		5*time.Second,
		errors.New("后台收尾超过五秒"),
	)
	return ctx
}

真实代码中仍应保存并调用返回的 CancelFunc，上面的函数为了突出关系而省略了资源所有者。更稳妥的做法是同时返回 Context 和取消函数，由调用方 defer cancel()，避免定时器和派生 Context 被无谓保留。

把取消原因当作一次性诊断记录

工程上可以把 cause 看成一次性写入的诊断记录：由最先决定“这项工作应停止”的边界写入，后续层只读取，不尝试改写。上游取消适合携带请求终止、服务关闭或租约失效等原因；下游本地取消适合携带解析失败、配额耗尽或业务条件不满足等原因。

记录日志时建议同时保存 ctx.Err() 和 context.Cause(ctx)：前者便于按取消/超时聚合，后者解释业务来源。函数本身的返回错误仍然要正常返回，不能只靠 Context 传递所有失败信息。Context 的主要职责是跨 API 边界传递截止时间、取消信号和请求级值，不是通用错误总线。

相关问题

context.Cause 在 Context 尚未取消时返回什么？

返回 nil。应先等待 Done() 或确认 Err() 非空，再把 Cause 当作取消原因读取。

调用 cancel(nil) 后 Cause 为什么不是 nil？

CancelCauseFunc(nil) 会把原因设置为 context.Canceled，用于保持已取消 Context 的 Cause 为非空错误。

子级取消会影响父级 Cause 吗？

不会。取消从父级向后代传播，不会从子级反向取消父级。子级先取消时可以保留自己的 cause，父级仍可在之后记录另一个原因。

如何确保测试稳定得到子级原因？

先调用子级取消函数并等待子级 Done()，确认 Cause 后再取消父级。不要让两个取消动作无同步地并发竞争。