Golang中Context取消信号的跨协程传播逻辑与语言学习并发实践

ctx.Done()必须用select监听而非ctx.Err()，因后者仅返回历史状态、不阻塞等待，无法响应未来取消；正确做法是select监听Done()通道以实时感知取消信号。

Context取消信号不是“通知”，而是“通道关闭”——所有监听ctx.Done()的协程会立刻感知，无需轮询或手动传递。

为什么ctx.Done()必须用select监听，不能只查ctx.Err()

因为ctx.Err()只反映“是否已取消”，不阻塞等待；它返回的是历史状态，无法响应未来的取消事件。一旦协程在耗时操作中（比如time.Sleep(10 * time.Second)），只检查ctx.Err()会导致它卡满10秒才退出。

• 正确做法是把<code>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取消传播的边界在哪

取消信号严格单向向下传播：父cancel → 所有子自动cancel；但子cancel不会影响父，也不会影响兄弟节点。这种隔离性允许你在同一请求中为不同子任务派生独立WithCancel子ctx，互不干扰。

立即学习“go语言免费学习笔记（深入）”；

• 子ctx调用自己cancel()，只关闭自己的Done()，父和其他子ctx不受影响
• WithValue派生的ctx不参与取消链，它只是查找链的一部分，不影响传播逻辑
• 注意：不要混用不同根的ctx（比如一个来自http.Request.Context()，另一个来自context.WithTimeout(context.Background(), ...)），应统一从同一个根派生

为什么ctx.Done()关闭后，ctx.Err()才返回非nil值

因为ctx.Err()内部就是读取一个原子变量或惰性计算结果，而Done()是底层真正被关闭的channel。channel关闭是同步、不可逆、协程安全的操作，所有监听者立即收到零值；Err()只是配套的“原因查询接口”。

• 你不能靠ctx.Err() == context.Canceled来触发退出，必须先让select从ctx.Done()收到信号
• 常见误用：在select里写case —— 正确；但写成<code>case 是冗余且易错的
• 如果需要区分取消原因（超时 vs 手动cancel），直接用ctx.Err()判断即可：errors.Is(ctx.Err(), context.DeadlineExceeded) 或 errors.Is(ctx.Err(), context.Canceled)

真正容易被忽略的是：取消信号传播不依赖任何goroutine调度或轮询，它本质是channel关闭的内存可见性保证。只要Done()被关闭，所有正在select等待它的goroutine都会在下一个调度点立即退出——这个“立即”是Go运行时保证的，不是近似值。