go中取消长任务的唯一推荐方式是通过context.context；应传入ctx并在i/o前或计算循环中高频检查ctx.err()，用带缓冲channel上报进度避免阻塞。
用 context.Context 控制长任务取消，别用全局 flag 或 channel 手动轮询
Go 中取消长任务的唯一推荐方式是通过 context.Context。手动维护一个 isCancelled bool 变量或靠 select 轮询一个取消 channel，容易漏检、竞态或阻塞。正确做法是把 ctx 传入任务函数，在关键检查点调用 ctx.Err() 判断是否需退出。
常见错误现象：任务已收到取消信号，但仍在执行下一轮循环；或 ctx.Done() channel 被多次 select，导致 goroutine 泄漏。
- 始终在 I/O 操作（如
http.Client.Do、time.Sleep、数据库查询）前检查ctx.Err() != nil - 避免在密集计算循环中只在循环头检查——应每 N 次迭代或每毫秒级耗时后检查一次，否则响应延迟高
- 不要重复关闭
ctx.Done()channel，它由 context 自动关闭；也不要把context.WithCancel返回的cancel函数暴露给下游，只传ctx
用带缓冲的 channel 上报进度，避免阻塞主流程
进度上报本质是生产者（长任务）→ 消费者（UI/日志/监控）的异步通信。若用无缓冲 channel，一旦消费者没及时接收，任务就会卡住；若用同步通知（如回调函数），又会把业务逻辑和上报耦合死。
典型场景：文件分块上传、批量数据导出、模型推理等需要实时反馈百分比或阶段信息的任务。
- 定义进度结构体，例如
type Progress struct { Percent int; Stage string; Error error } - 创建带缓冲的 channel：
progress := make(chan Progress, 10)（缓冲大小按上报频率和消费延迟预估） - 任务中非阻塞发送：
select { case progress ，防止消费者宕机时拖垮任务 - 消费者端用
for p := range progress持续读取，注意在任务结束前关闭 channel（由任务协程 close）
context.WithTimeout 和 context.WithCancel 的选择依据
两者都返回可取消的 context，但触发条件不同：前者到时间自动取消，后者需显式调用 cancel()。选错会导致行为不符合预期——比如用户点击“取消”却只能等超时，或设了超时却忘了手动 cancel 导致资源泄漏。
性能与兼容性影响：所有标准库（net/http、database/sql 等）都原生支持 context.Context，无需额外适配；但超时精度受系统调度影响，Windows 下可能有几十毫秒偏差。
- 用户主动取消（如按钮点击）→ 用
context.WithCancel，并在 UI 层调用cancel() - 防呆/防挂起（如 API 最多执行 30 秒）→ 用
context.WithTimeout(ctx, 30*time.Second) - 既要用户取消又要超时兜底 →
context.WithTimeout套在context.WithCancel外层，或用context.WithDeadline - 切勿对同一个
cancel()函数多次调用，第二次及以后是空操作，但可能掩盖逻辑错误
组合使用时的坑：进度 channel 关闭时机和 context 取消顺序
最常被忽略的是：任务因 context 取消而提前退出时，progress channel 是否已关闭？如果没关，消费者会永远阻塞在 range 上；如果过早关闭，可能丢掉最后几条进度。
真实调试中容易看到的现象：fatal error: all goroutines are asleep - deadlock，或进度停在 98% 不再更新。
- 必须在任务函数 return 前关闭 channel：
close(progress)，且仅关闭一次 - 不要在
defer close(progress)里关——若任务 panic，channel 可能未发完就关闭；应在正常退出和所有 error return 分支末尾显式 close - context 取消后，任务应尽快停止发送新进度，但允许把已构造好的最后一条（如 “cancelled”）发出去，再 close
- 消费者需处理
progress关闭后的退出，不能假设它永远有数据
