在Go语言中，取消信号的处理应使用select监听ctx.Done()而非ctx.Err()，因为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()函数：谁应该调用，何时调用？
只有创建该context的父协程（或明确负责生命周期的协程）才有资格调用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运行时保证的，不是近似值，也不是概率事件。
