Go context.WithCancel 在长任务中如何按阶段提前释放

长任务往往不是一个函数从头跑到尾，而是依次完成读取、处理、写入等阶段。如果所有阶段共用一个最外层的 context.WithCancel，阶段已经结束后，派生上下文仍可能一直保留到整个任务返回。更稳妥的做法是：请求上下文负责总生命周期，长任务上下文负责任务级取消，每个阶段再创建自己的子上下文，并在阶段函数返回时立即调用对应的 cancel。

还要注意，CancelFunc 只是发出取消信号，不会等待 goroutine 自己退出。因此阶段函数既要及时释放资源，也要让阻塞中的 worker 监听 Done，最后通过 WaitGroup 或结果通道完成收尾。

先划清长任务与阶段上下文的边界

Go 官方文档把上下文描述为一棵派生树：父上下文取消后，所有子上下文都会收到取消信号；主动调用子节点的 cancel，则只影响该节点及其后代。因此可以把边界设计成“请求 > 任务 > 阶段”。请求结束时整棵树停止，某个阶段失败时只取消该阶段和它的 worker。

阶段不要把 context.Context 存进结构体，也不要为了“方便”传入 nil。让它作为函数第一个参数传递，阶段函数只持有自己需要的那一层上下文，生命周期会更容易推断。

把 cancel 放进阶段函数，而不是长任务外层

关键写法是把每个阶段拆成独立函数。这样 defer cancel() 的作用域就是当前阶段：正常返回、上游取消和中途报错都会执行它。

func runJob(ctx context.Context, items []Item) error {
	// 任务上下文负责贯穿整个长任务，不替代请求上下文。
	jobCtx, jobCancel := context.WithCancel(ctx)
	defer jobCancel()

	if err := runPhase(jobCtx, items); err != nil {
		// 阶段失败时，立即让任务级子节点停止后续工作。
		return err
	}
	return nil
}

func runPhase(parent context.Context, items []Item) error {
	// 阶段返回时释放自己的派生上下文，不把资源留到 runJob 结束。
	phaseCtx, cancel := context.WithCancel(parent)
	defer cancel()

	for _, item := range items {
		if err := phaseCtx.Err(); err != nil {
			// 主动取消和上游取消都应尽快离开阶段循环。
			return err
		}
		if err := processOne(phaseCtx, item); err != nil {
			cancel()
			return err
		}
	}
	return nil
}

这里的重点不是多写一层函数，而是让资源所有权明确：runPhase 创建了 phaseCtx，所以它也负责释放；调用方只处理阶段结果，不需要猜测何时再调用一次 cancel。若阶段中有多个可取消的外部调用，也应把同一个 phaseCtx 传下去，而不是重新回到父上下文。

让每个阶段自己释放 cancel 并通知同伴

当阶段内部启动多个 worker 时，单纯调用 cancel() 还不够。每个 worker 的阻塞发送、接收或外部调用都必须选择 ；阶段函数还要等待 worker 退出，否则返回值已经出来，后台 goroutine 仍可能继续占用资源。

func runWorkers(parent context.Context, jobs []Job) error {
	// 一个阶段共享同一个取消源，首个错误可以通知所有 worker。
	ctx, cancel := context.WithCancel(parent)
	defer cancel()

	errs := make(chan error, len(jobs))
	var wg sync.WaitGroup
	for _, job := range jobs {
		job := job
		wg.Add(1)
		go func() {
			defer wg.Done()
			if err := doJob(ctx, job); err != nil {
				select {
				case errs 

示例中的 ctx.Err() 可能为 nil，也可能是 context.Canceled。生产代码可以把首个业务错误单独保存，再在所有 worker 退出后返回它；不要因为某个 worker 收到取消就把它记录成新的故障。

用错误类型判断阶段该怎么结束

context.Canceled 表示取消信号，context.DeadlineExceeded 表示截止时间到达，它们通常不应按业务异常重复重试。真正的文件格式错误、远端返回错误或数据校验错误，才进入业务错误处理。判断时使用 errors.Is，不要直接比较错误字符串。

相关问题

调用 cancel 后 goroutine 会立刻消失吗？

不会。cancel 只关闭取消信号，goroutine 必须主动监听 Done 并返回，调用方还应使用 WaitGroup 或等价机制确认它们已经退出。

每个循环迭代都要创建一个 WithCancel 吗？

不一定。只有当每次迭代有独立生命周期或需要单独提前停止时才这样做；否则按“一个阶段一个上下文”划分，通常更容易控制资源和错误。

为什么已经超时还要 defer cancel？

超时会关闭上下文的 Done，但显式调用 cancel 仍能尽早释放派生上下文关联的资源，并让代码在正常完成和超时路径上保持一致。