Go 自动化任务怎样用 context 传递取消：触发、排队与收尾边界

自动化任务被手动停止或超过截止时间时，真正难处理的不是发出取消信号，而是让触发端、等待中的任务和已经运行的 worker 都看见同一个结果，并在退出前把状态写完整。Go 的 context.Context 适合做这条控制线：上游创建派生 context，下游监听 Done()，结束时用 Err() 区分取消和超时。

把 context 当成“停止工作的广播”，把任务状态和 WaitGroup 当成“收尾账本”：取消只负责通知，worker 必须主动响应，调度器还要等待它们退出后再确认本轮结束。

先把一轮任务拆成三段控制线

假设流水线每轮要处理一组仓库：触发器收到停止请求后，不能只让当前函数返回，因为队列里可能还有未领取的任务，worker 也可能卡在等待结果。比较稳的拆法是三段：

• 触发器创建 ctx, cancel，决定何时取消。
• 调度器从输入队列取任务，取消后不再把新任务交给 worker。
• worker在实际工作和发送结果的阻塞点监听 ctx.Done()，收到信号后释放自己的资源。

这三个角色共享的是 context 的取消信号，不是共享一个布尔字段。官方文档还特别提醒，调用 CancelFunc 会释放关联资源，因此创建派生 context 后应保证 cancel 在所有控制流路径上都会被调用。

用一个最小流水线传递取消信号

下面的例子刻意保留了任务队列、worker 和收口等待三个节点。run 返回前，所有 worker 都必须经过 Wait；否则上层看到“已取消”，后台仍可能在写结果。

package main

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

type Job struct{ ID int }

func worker(ctx context.Context, jobs 

这里的 ctx.Done() 同时保护取任务和处理任务两个等待点；close(jobs) 只表示调度器不会再发送新任务，worker 的退出仍由队列关闭或 context 取消共同决定。最后的 ctx.Err() 可能是 nil、context.Canceled 或 context.DeadlineExceeded，调用方可以据此区分自然完成、人工停止和截止时间到期。

排队阶段为什么也要监听 Done

只在 worker 内部检查取消还不够。调度器若一直阻塞在 jobs ，而所有 worker 已经因取消退出，它自己就没有机会关闭队列或进入 Wait。因此发送动作要和 ctx.Done() 放在同一个 select 中。

任务已经从输入集合取出但尚未发送时，取消意味着“不要再开始这项工作”；任务已经发送给 worker 后，取消意味着“允许它在下一个可中断点退出”。这两个时间点不要混写成一个全局状态，否则很难解释为什么少数任务已经产生结果。

取消、超时和自然完成分别怎么落账

人工取消要保留原始原因

如果上层调用 cancel()，下游通常看到 context.Canceled。这表示本轮被主动停止，不应被记录成 worker 处理失败。需要业务原因时，可以用 context.WithCancelCause 传递更具体的错误，再用 context.Cause 读取它；但任务状态仍建议单独保留“已取消”这一类。

截止时间到期不是普通失败

WithTimeout 或 WithDeadline 触发后，Err() 返回 context.DeadlineExceeded。日志里至少记录已领取数量、已完成数量和剩余输入，下一轮才能判断是延长时限、减少并发还是拆分任务。

自然完成也要走同一条等待路径

输入发送完后关闭 jobs，worker 依次读到 ok == false 并退出，wg.Wait() 返回后才算自然完成。不要因为队列已关闭就跳过等待，关闭 channel 不等于 goroutine 已经退出。

四个容易让流水线失控的细节

1. 忘记 defer cancel：短任务也应释放派生 context 的资源；把 cancel 放在创建位置附近更不容易漏。
2. 把 context 存到结构体：任务对象应携带业务数据，context 作为需要它的函数的第一个参数显式传下去。
3. 只在循环顶部检查：阻塞在 channel、网络或定时器时，顶部检查根本不会执行，必须把 Done() 放进对应的 select。
4. 先返回再 Wait：上层若据此马上启动下一轮，旧 worker 可能还在写同一份结果。收口顺序应是停止接收、关闭队列、等待 worker、再写最终状态。

用可复查结果确认取消真的生效

测试时不要只断言返回了 context.Canceled。还要核对 worker 数量最终归零、没有新的任务发送、结果写入没有越过取消时刻。可以为每个 job 记录 queued、started、finished 和 skipped，这样一次取消后哪些任务被丢在队列里一目了然。

如果使用超时测试，时间只用来制造边界，不要把固定 sleep 当成同步手段。更稳的做法是用可控 channel 发出“允许继续”的信号，再触发 cancel，最后等待 worker 退出；测试的断言应建立在事件和状态上。

相关问题

context 能不能代替任务状态表？

不能。context 只表达取消、截止时间和请求范围值，不能记录某个任务已经写入哪一批结果。任务状态仍应由业务结构或持久化记录维护。

worker 忽略 Done 会发生什么？

它可能继续占用连接、文件或 CPU，调用方即使拿到取消错误也无法确认资源已经释放。对无法直接接收 context 的第三方调用，应把调用隔离并设计明确的超时与回收边界。

收尾检查

一轮自动化任务可以用四个问题验收：取消是否从触发器传到了每个 worker？排队发送是否能被 Done 打断？所有 worker 是否在最终状态写入前完成 Wait？日志能否区分自然完成、主动取消和截止时间到期？四项都能回答，context 才真正成为流水线的控制线，而不是一个被层层透传却没人监听的参数。