如何在Golang中实现并发任务取消_Golang context取消机制示例

context.WithCancel 是最直接的取消触发方式，返回可取消的 Context 和 cancel 函数，调用后者协作式通知监听 goroutine 退出；必须传入 ctx 并用 select + ctx.Done() 检测取消，避免泄漏和误用。

context.WithCancel 是最直接的取消触发方式

当你需要手动控制一个任务的生命周期，比如用户点击“停止”按钮、超时前主动终止爬虫请求，context.WithCancel 是首选。它返回一个可取消的 context.Context 和一个 cancel 函数，调用后者即向所有监听该 context 的 goroutine 发送取消信号。

关键点在于：取消是**协作式**的，不是强制杀掉 goroutine；每个 goroutine 必须主动检查 ctx.Done() 并退出。

• 必须在 goroutine 启动前把 ctx 传入，不能在内部重新创建子 context（除非有明确传递链）
• cancel() 可被多次调用，但后续调用无实际效果，不会 panic
• 忘记调用 cancel() 会导致底层 channel 泄漏，尤其在循环中重复创建时要格外小心

ctx, cancel := context.WithCancel(context.Background())
defer cancel() // 防止泄漏，但注意：仅适用于单次使用场景
go func(ctx context.Context) {
for i := 0; i < 10; i++ {
select {
case <-time.After(time.Second):
fmt.Println("working...", i)
case <-ctx.Done():
fmt.Println("cancelled:", ctx.Err()) // context canceled
return
}
}
}(ctx)
time.Sleep(3 * time.Second)
cancel()

select + ctx.Done() 是唯一可靠的取消检测模式

在 goroutine 内部，不能靠轮询 ctx.Err() != nil 来判断是否被取消——这会错过取消瞬间，且浪费 CPU。正确做法永远是用 select 等待 ctx.Done() 这个只读 channel。

ctx.Done() 在 context 被取消或超时时自动关闭，此时 select 分支可立即响应。若 context 未取消，该分支阻塞，不消耗资源。

• 不要在 select 外单独检查 ctx.Err()，那是无效的“事后补救”
• 如果 goroutine 正在执行阻塞 IO（如 http.Get），需确保该操作本身支持 context（例如用 http.NewRequestWithContext）
• 自定义阻塞操作（如数据库查询）必须显式集成 ctx，否则无法响应取消

context.WithTimeout 和 context.WithDeadline 本质相同，但语义不同

context.WithTimeout(ctx, 2*time.Second) 和 context.WithDeadline(ctx, time.Now().Add(2*time.Second)) 最终行为一致：都会在约 2 秒后触发取消。区别在于可读性与适用场景：

• WithTimeout 更适合“最多运行 N 秒”的逻辑，比如 API 请求最大等待时间
• WithDeadline 更适合“必须在某个绝对时间点前完成”，比如和外部系统约定截止时刻
• 两者都依赖系统时钟，若机器时间被大幅调整（如 NTP 校正），WithDeadline 可能提前或延后触发

注意：timeout 是相对当前时间的偏移量，不是从 goroutine 启动开始计时——它从 WithTimeout 调用那一刻起算。

子 context 的取消会自动传播到所有后代

Go 的 context 取消是树状传播的：父 context 被取消，所有通过 WithCancel/WithTimeout/WithDeadline 创建的子 context 也会同时被取消，无需手动管理层级。

但要注意：子 context 的取消**不会反向影响父 context**。也就是说，你可以在一个长生命周期的 context 上派生多个短期任务，各自独立取消，互不干扰。

• 避免把同一个 cancel 函数到处传递并多次调用，容易引发竞态或误取消
• HTTP handler 中常用 r.Context() 作为根 context，再派生带 timeout 的子 context 用于下游调用
• 数据库连接池、日志上下文等中间件应始终接收并透传 context，否则取消信号会在某一层断掉

真正难的不是写对那几行 select，而是确保整个调用链路每一层都尊重 ctx —— 少一个 select，就少一处取消入口。