Go context.WithCancelCause 如何在并发任务中保留首个失败原因

批量读取用户资料时，某个后端请求先返回了权限错误，其他 goroutine 随后也陆续退出。日志里只剩一句“context canceled”，真正的失败原因反而不见了。这个场景适合用 context.WithCancelCause：协调函数收到第一个错误后取消整个任务组，同时把原因挂到 context 上，调用方最后可以从 context.Cause 读出它。

把取消当作控制信号，把 cause 当作诊断结果；两者一起传递，才能既及时停工，又保留首个失败原因。

为什么只返回 context canceled 不够

普通的 context.WithCancel 只能表达“任务结束了”，不能表达“为什么结束”。在批量任务里，先失败的 goroutine 可能是 permission denied，另一个 goroutine 则因为收到取消信号返回 context canceled。如果协调层只记录后一个错误，排障方向就会被带偏。

WithCancelCause 返回的取消函数接受一个 error。第一次传入的非空错误会成为 context 的 cause；之后再调用取消函数，不会把它覆盖掉。这个“首个原因”规则很适合一组并发任务共享一个失败出口。

让首个错误沿 ctx.Done 回到协调函数

示例把读取动作收敛在 loadProfile，由 runBatch 创建带 cause 的 context。为了让逻辑可以复现，第二个任务模拟权限失败，其他任务在发现取消后提前退出。

package main

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

var errPermission = errors.New("permission denied")

func loadProfile(ctx context.Context, id int) error {
    select {
    case 

这里的调用链是 runBatch 创建 ctx，各个 loadProfile 监听 ctx.Done，失败任务调用 cancel(err)，最后由 context.Cause(ctx) 读取原因。代码只关心这四个真实节点，图片也只呈现这条链。

为什么要把 id := id 放进循环体

这个细节与 cause 无关，却会直接影响复现实验。在 goroutine 闭包里先复制当前 id，每个任务才会拿到自己的用户编号；否则不同 Go 版本或不同写法下，闭包捕获循环变量很容易造成任务与编号错配。先保证任务身份稳定，再观察取消路径。

取消信号和业务错误要分开判断

收到 ctx.Done() 的任务不应该把自己的退出当成首个业务故障。它们返回的 ctx.Err() 多半只是后果。调用方需要优先读 context.Cause(ctx)，只有没有 cause 时，才把 ctx.Err() 作为超时或主动取消依据。

可以把判断集中在调用方：

err := runBatch(ctx, ids)
if errors.Is(err, errPermission) {
    // 业务失败：修复权限或提示调用方
} else if errors.Is(err, context.DeadlineExceeded) {
    // 时间预算耗尽：按策略重试
} else if err != nil {
    // 其他根因继续记录
}

并发收敛时容易踩的三个坑

用 defer cancel(nil) 覆盖首个错误

只要先前已经调用过 cancel(err)，后面的 cancel(nil) 不会覆盖 cause，所以这种清理写法是安全的。真正危险的是在业务失败前主动调用了 cancel(nil)，那会让 context 进入取消状态，却失去后续诊断机会。

只在协调函数里检查取消

如果 loadProfile 内部正在等待网络、队列或定时器，却没有把等待写成同时选择 ctx.Done()，任务就不能及时退出。每一个可阻塞点都要有取消分支，尤其是数据库查询、HTTP 请求和 channel 接收。

把最后返回的错误当成首个错误

并发任务完成顺序不稳定，最后一个 goroutine 返回的错误没有诊断优先级。让共享的取消函数记录首个 cause，再由主 goroutine统一读取，结果才可解释。

如何验证首个失败原因没有丢

运行程序后，预期输出是 permission denied，而不是某个被取消任务的 context canceled。可以把 id == 2 改成 id == 4 再运行一次，观察首个业务错误变化；也可以给父 context 加一个很短的 deadline，确认没有业务错误时返回 context deadline exceeded。

生产代码还应记录任务 ID、cause 和父 context 的截止时间。不要为了让所有任务“优雅完成”而忽略取消，这会让失败批次继续占用连接和 goroutine。

相关问题

WithCancelCause 会保存多个错误吗？

不会。它保存首个 cause；如果需要完整错误列表，应另建并发安全的收集结构，不能把 context 当错误聚合器。

没有业务错误时 context.Cause 返回什么？

在 context 尚未取消时返回 nil。若父 context 因超时或取消结束，cause 会沿父子关系传递。

取消后还应该启动新的 goroutine 吗？

通常不应该。先检查 ctx.Err() 或 ctx.Done()，只有明确属于独立收尾任务时，才使用不受该 context 影响的生命周期。

把 cause 当作诊断出口

context.WithCancelCause 的价值不在于多一个 API，而在于把“停止工作”和“解释停止原因”拆成两个清晰动作：任务组用 cancel(err) 快速收敛，调用方用 context.Cause 保留诊断。只要每个阻塞点都监听 ctx.Done，这条错误链就能在并发场景里稳定工作。