ctx.Done()必须用select监听而非ctx.Err()，因后者仅返回历史状态、不阻塞等待，无法响应未来取消；正确做法是select监听Done()通道以实时感知取消信号。
Context取消信号不是“通知”，而是“通道关闭”——所有监听ctx.Done()的协程会立刻感知，无需轮询或手动传递。
先说几个关键点。关于Context取消机制，很多开发者容易踩坑，其中一个核心误区就是试图用ctx.Err()来替代ctx.Done()的监听。原因很简单：ctx.Err()只告诉你“是否已经取消”，它不阻塞、不等待，返回的是历史快照，而不是未来的信号。如果你在协程里执行一个耗时操作，比如time.Sleep(10 * time.Second)，而只检查ctx.Err()，那这个协程会硬生生卡满10秒才退出，完全无法响应中途发生的取消请求。
- 正确做法：用
select监听ctx.Done()，一旦通道关闭，立即响应。 - 错误写法：
if ctx.Err() != nil { return }—— 这只能捕获已发生的取消，对后续发生的事件毫无反应。 - 特殊情况：如果操作本身不支持context（比如
os.ReadFile），那么需要在循环中定期检查ctx.Err()，而不是依赖Done()通道。
WithCancel返回的cancel()函数谁该调用、何时调用
只有创建它的父协程（或明确负责生命周期的协程）才有资格调用cancel()。子协程绝对不能主动调用——否则可能提前中断其他共享同一ctx的协程，引发不可预料的连锁反应。
cancel()可以安全重复调用，但语义上应只调用一次。多次调用虽然不会panic，但可能掩盖逻辑错误，给调试埋下隐患。- 典型场景：HTTP handler里启动goroutine处理后台任务，应在handler返回前调用
cancel()，通常配合defer使用，确保资源及时释放。 - 如果使用了
WithTimeout，timer到期会自动调用cancel()。此时再手动调用，会提前停掉timer，这其实是预期行为，不是bug——但要注意，手动调用会覆盖自动超时的语义。
父子Context取消传播的边界在哪
取消信号严格单向向下传播：父context取消，会级联取消所有子context；但子context取消不会影响父，也不会影响兄弟节点。这种隔离性非常实用，允许你在同一请求中为不同子任务派生独立的WithCancel子ctx，互不干扰。
- 子ctx调用自己的
cancel()，只关闭自己的Done()通道，父和其他子ctx稳如泰山。 WithValue派生的ctx不参与取消链，它只是查找链的一部分，不影响传播逻辑。- 注意：不要混用不同根的ctx。比如一个来自
http.Request.Context()，另一个来自context.WithTimeout(context.Background(), ...)，应该统一从同一个根派生，否则取消信号无法正确传播。
为什么ctx.Done()关闭后，ctx.Err()才返回非nil值
这背后是Go内部实现机制的问题。ctx.Err()本质上读取一个原子变量或惰性计算结果，而Done()是底层真正被关闭的channel。channel关闭这个操作是同步、不可逆、协程安全的，所有监听者会立即收到零值。Err()只是配套的“原因查询接口”，用来告诉你取消的原因是什么。
- 不能靠
ctx.Err() == context.Canceled来触发退出，必须先让select从ctx.Done()收到信号。 - 常见误用：在
select里写case —— 正确；但写成case 是冗余且易错的，没必要。 - 如果需要区分取消原因（超时还是手动cancel），直接用
ctx.Err()判断即可：errors.Is(ctx.Err(), context.DeadlineExceeded)或errors.Is(ctx.Err(), context.Canceled)。
但真正的关键往往被忽略：取消信号传播不依赖任何goroutine调度或轮询，它本质是channel关闭的内存可见性保证。只要Done()被关闭，所有正在select等待它的goroutine都会在下一个调度点立即退出——这个“立即”是Go运行时保证的，不是近似值，也不是概率事件。
