Go context.WithCancelCause 返回的 cancel 如何让下游读到原因

我在给一条并发任务链加取消信号时，最容易遇到的误区是：上游明明知道“配额耗尽”或“用户主动停止”，下游收到的却只有 context canceled。原因通常不是传播失败，而是把 ctx.Err() 当成了完整原因。

context.WithCancelCause 的正确用法是：上游调用返回的 cancel(err) 记录具体错误；下游等到 Done() 关闭后，用 context.Cause(ctx) 读取它。ctx.Err() 仍适合判断是否被取消，但不会替代具体 cause。

先把 cancel 的输入和两个读取入口分清

普通的 context.WithCancel 返回无参数的 CancelFunc；而 WithCancelCause 返回的函数可以接收 cause。这个差异只改变“取消时如何记录原因”，并没有改变 Done 的传播方式。

package main

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

var ErrQuotaExceeded = errors.New("quota exceeded")

func main() {
	// 上游创建可记录原因的上下文，并把派生上下文交给下游。
	ctx, cancel := context.WithCancelCause(context.Background())
	defer cancel(nil) // 正常返回时也释放上下文资源；已有 cause 不会被覆盖。

	child, childCancel := context.WithCancelCause(ctx)
	defer childCancel(nil) // 子上下文由本层创建，本层负责清理。

	// 业务失败点把具体错误写入取消信号，而不是只调用无参 cancel。
	cancel(ErrQuotaExceeded)

	

这个示例的关键不在于打印，而在于读取方式。示意结果会是：

Err: context canceled
Cause: quota exceeded

因此，统一的取消分支可以继续用 errors.Is(err, context.Canceled) 判断；需要记录“为什么取消”时，再读取 context.Cause(child)。

下游要在 Done 关闭后读取自己的 cause

下游函数不需要知道上游保存了哪个变量，只要接收 context.Context 并遵循取消协议即可。这样做的好处是，函数可以被不同父上下文复用：有 cause 时读到具体错误，没有 cause 时仍能得到与 Err() 相同的取消结果。

func consume(ctx context.Context) error {
	select {
	case item := 

实际项目中把 loadItem 这类阻塞操作也设计成接收 Context，才能让取消继续深入数据库、HTTP 或队列调用。仅在外层读取 cause，并不能自动中断一个完全不监听 ctx.Done() 的下游函数。

Err 和 Cause 不要混成一个错误字段

可以把它们理解为两层信息：

如果用 WithCancelCause 后调用 cancel(nil)，cause 会落到取消语义本身；如果是截止时间触发，通常应按 DeadlineExceeded 处理。不要为了让日志更详细，把业务错误塞进 Context Value；cause 本来就是这条取消链路的语义。

最容易丢原因的是取消顺序和清理责任

取消原因遵循“第一次取消生效”。如果父 Context 先带着原因取消，子 Context 看到的就是父级原因；如果子 Context 先以另一个原因取消，子级会保留自己的 cause，之后父级再取消也不会覆盖它。因此不要在多个层级随意抢先调用取消函数，否则日志中的原因可能和你预期不同。

工程上建议让创建者拥有取消函数：创建子 Context 的函数负责 defer cancel(nil)，真正知道业务失败的层级调用带 error 的取消函数；所有下游都只负责监听和返回。这样既能释放关联资源，也能避免把一个取消函数到处传递造成重复决策。

相关问题

为什么下游的 Err 不是我传入的业务错误？

这是预期行为。Err() 返回通用取消类别；业务错误请读取 context.Cause(ctx)。

把 cause 放到 Context Value 里可以吗？

不建议。Value 面向请求范围的数据传递，取消原因应由 CancelCauseFunc 记录，语义更清楚，也能随取消链路传播。

父级取消后子级还能改 cause 吗？

不能覆盖已经发生的第一次取消。需要保留哪一个原因，应在设计父子 Context 和取消顺序时明确责任边界。