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() // 防止泄漏，但注意：仅适用于单次使用场景
<p>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)</p><p>time.Sleep(3 * time.Second)
cancel()select + ctx.Done() 是唯一可靠的取消检测模式
在 goroutine 内部，不能靠轮询 ctx.Err() != nil 来判断是否被取消——这会错过取消瞬间，且浪费 CPU。正确做法永远是用 select 等待 ctx.Done() 这个只读 channel。
ctx.Done() 在 context 被取消或超时时自动关闭，此时 select 分支可立即响应。若 context 未取消，该分支阻塞，不消耗资源。
立即学习“go语言免费学习笔记（深入）”；
- 不要在
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，就少一处取消入口。
