Go context.WithCancelCause 怎样把取消原因传给调用方在批处理代码中减少额外分配

批处理里经常同时需要两件事：让所有 worker 尽快停止，还要告诉调用方究竟是哪一个任务先失败。只返回 context.Canceled 能表达“停了”，却丢掉了“为什么停”。更合适的做法是用 context.WithCancelCause 创建一次批次级上下文：ctx.Err() 继续表示取消状态，context.Cause(ctx) 负责取回首个取消原因。

官方地址：https://pkg.go.dev/context#WithCancelCause

先区分 Err 和 Cause：状态与原因不是一回事

WithCancelCause 的行为和 WithCancel 类似，但返回的取消函数可以接收一个错误。传入非 nil 错误后，ctx.Err() 仍然是 context.Canceled，而 context.Cause(ctx) 返回传入的原始错误；传入 nil 时，原因也会落为取消错误。

把取消原因放在批次边界，而不是每条任务上

批处理的性能关键是派生边界。一个批次创建一次 WithCancelCause，worker 只接收这个 ctx；某个 worker 发现不可继续的错误时调用同一个 cancel。这样取消信号通过 Context 广播，调用方不需要为每个任务分配一个“错误加取消状态”的结果包装对象。

package main

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

// ErrInvalidRecord 是可复用的哨兵错误，避免每条记录都创建相同错误文本。
var ErrInvalidRecord = errors.New("批次中存在无效记录")

func runBatch(parent context.Context, records []string) error {
	ctx, cancel := context.WithCancelCause(parent)
	defer cancel(nil) // 批次正常收尾时释放派生 Context 的资源。

	var wg sync.WaitGroup
	for _, record := range records {
		record := record // 为当前 goroutine 固定本轮字符串值。
		wg.Add(1)
		go func() {
			defer wg.Done()
			select {
			case 

这里的“减少额外分配”是工程边界，不是对标准库做无条件的性能承诺：Context 本身仍有创建成本，真正的收益来自“每个批次一次派生”和“复用稳定错误”，避免每条记录再构造错误包装、取消通道或状态对象。若任务本来就需要返回每条记录的详细结果，仍应使用明确的结果结构，不能为了省分配丢掉业务信息。

调用方先判断取消，再读取首个原因

worker 只负责触发取消，批次入口负责统一解释结果。不要直接把 context.Cause(ctx) 当成所有错误的替代品：只有 Context 已取消后它才有意义；正常完成时它返回 nil。

func reportBatch(ctx context.Context) error {
	if err := ctx.Err(); err == nil {
		return nil // 没有取消，说明批次没有走取消错误分支。
	}

	// Cause 保留首个取消原因，Err 则保持稳定的取消状态。
	cause := context.Cause(ctx)
	if cause == nil {
		return context.Canceled // 兜底处理自定义 Context 的异常情况。
	}
	return fmt.Errorf("批处理未完成: %w", cause)
}

父子 Context 的取消存在先后关系：父 Context 先取消时，子 Context 会继承父原因；子 Context 先取消时，子 Context 可以保留自己的原因。无论哪种情况，已经设置的原因都不会被后续取消覆盖，因此“首个原因”应当作为批次诊断契约写进接口说明。

控制分配与生命周期的迁移清单

• 一个批次只创建一次 context.WithCancelCause，不要在循环体内为每条记录派生。
• 可复用的固定错误定义为包级哨兵；需要上下文信息时再按需包装，并限制包装次数。
• 所有 worker 都通过 观察取消，调用方通过 Err 判断状态、通过 Cause 解释原因。
• 拿到取消函数后用 defer cancel(nil) 收尾，异常分支再提前调用 cancel(cause)。
• 不要把 Context 当作每条任务的结果容器；需要逐项结果时保留明确的结果结构。

可以把这套写法记成一句话：批次级 Context 负责广播停止，Cause 负责携带首错，Err 负责保持兼容。 这样既让上层拿到可判断的取消状态，也不会为了传递同一个批次原因而在每条记录上重复创建状态对象。

相关问题

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

如果这是第一次取消，原因会是 context.Canceled；如果父 Context 已经先取消，则子 Context 会保留父级原因。

能不能用 context.WithCancel 之后再单独传 error？

可以，但需要额外的错误通道、共享变量或结果对象，并自行处理并发可见性与生命周期。批次级原因明确时，WithCancelCause 能把这层契约直接放进 Context。

WithCancelCause 一定比 WithCancel 更快吗？

不一定。它的价值是把取消原因和取消信号绑定在同一个批次边界；是否减少分配要看你是否因此省掉了额外的错误包装、通道或状态对象，应通过自己的基准测试确认。