context.context 是 go 中实现协作式任务取消的标准方案，它通过封装 channel 提供超时、取消和值传递能力，要求在 goroutine 中定期检查 ctx.done() 并响应取消信号。
Go 中用 context.Context 配合 channel 实现任务撤回才是正解
直接用 channel 做“撤回”容易误以为能中断正在运行的 goroutine，其实不能。Go 没有强制终止 goroutine 的机制，所谓“撤回”本质是协作式取消：让目标逻辑主动检查是否该退出。context.Context 就是为此设计的标准方案，它底层用 channel 通信，但封装了超时、取消、值传递等语义，比裸 channel 更可靠。
常见错误现象：select 中只监听结果 channel，完全忽略取消信号；或把 done channel 关闭后没做任何响应；或在 goroutine 启动后就丢掉 context 引用，导致无法传播取消信号。
- 必须在启动 goroutine 时传入
ctx，并在内部定期检查ctx.Done() - 不要自己造
donechannel —— 用context.WithCancel或context.WithTimeout创建 - 所有阻塞操作（如
time.Sleep、http.Do、ch ）都应配合 <code>ctx使用，比如改用time.AfterFunc或带Context的 client 方法
select 里怎么安全响应取消信号
关键不是“怎么监听”，而是“监听后怎么做”。裸写 case 很常见，但容易漏掉清理工作或资源泄漏。
使用场景：长循环任务、轮询、流式处理。例如一个持续从 channel 拉取数据并处理的 worker。
立即学习“go语言免费学习笔记（深入）”；
参数差异：ctx.Done() 返回的是只读 channel，关闭后会立即可读；而 ctx.Err() 在关闭后返回 context.Canceled 或 context.DeadlineExceeded，用于区分原因。
- 每个
select必须包含case 分支，且该分支应负责释放资源（如关闭文件、断开连接） - 避免在
default分支里跳过取消检查 —— 这会让取消延迟甚至失效 - 如果任务涉及多个 channel 操作，把
ctx.Done()和业务 channel 放在同一个select中，而不是嵌套或分离
select {
case item := <-workCh:
process(item)
case <-ctx.Done():
log.Println("worker canceled:", ctx.Err())
return // 注意：这里应加 cleanup
}为什么别用 chan struct{} 自己实现取消
有人用 done := make(chan struct{}) 然后 close(done) 来模拟取消，这在简单场景看似可行，但很快会暴露问题：无法传递取消原因、无法组合多个 context、无法与标准库生态（如 net/http、database/sql）对齐。
性能影响：裸 chan struct{} 占用更少内存，但失去 cancel propagation 能力后，往往需要额外 channel 或 mutex 来同步状态，反而更重。
-
context.WithCancel返回的cancel()函数会自动关闭其关联的Done()channel，并通知所有子 context - 标准库中几乎所有可取消操作（如
http.Client.Do、time.AfterFunc）都只接受context.Context，不认自定义 done channel - 测试时难 mock：你没法轻易伪造一个“已取消”的自定义 done channel，但可以调用
cancel()后传入ctx
goroutine 已经卡死在系统调用里怎么办
这是最常被忽略的复杂点。当 goroutine 阻塞在 read、write、accept 等系统调用上时，即使 ctx.Done() 已关闭，它也不会立刻响应 —— 因为 Go runtime 不会强行中断系统调用。
解决路径只有两条：一是换用支持 context 的封装（如 net.Conn.SetReadDeadline 配合 ctx 超时），二是用可中断的原语（如 net.Dialer.DialContext、os.File.ReadAt 配合 syscall 级控制）。
- HTTP 客户端务必用
http.DefaultClient.Do(req.WithContext(ctx))，而不是先创建再发请求 - TCP 连接请用
&net.Dialer{KeepAlive: 30 * time.Second}.DialContext(ctx, "tcp", addr) - 文件读写若需精确控制，考虑用
os.OpenFile后设置SetReadDeadline，而非依赖io.Copy的默认行为
真正棘手的不是语法怎么写，而是哪些阻塞点根本不会响应 ctx —— 比如 runtime.Gosched() 不行，for {} 死循环也不行，这些地方必须手动插入 ctx.Err() != nil 判断。
