Go Context取消信号单向向下传播，父ctx取消后子ctx几乎同时收到信号，但前提是每层goroutine持续监听ctx.Done()或循环中检查ctx.Err()；常见失效原因包括只单次检查、select漏case、硬编码Background、混用WithValue与取消逻辑、panic未recover等。
Go 的 Context 取消信号不是广播，而是单向向下传播的树形链路；父 ctx 一取消，所有子 ctx 几乎同时收到信号——但前提是每一层都真正在监听 ctx.Done()，且没忽略 ctx.Err()。
为什么子 goroutine 没退出？常见监听失效场景
取消信号到达了，但 goroutine 还在跑，通常不是 Context 机制失效，而是监听逻辑没写对。
- 只在函数开头
select一次监听ctx.Done()，后续循环中不再检查 —— 超时后仍在处理旧任务 - 用
if err := ctx.Err(); err != nil { return }判断，但放在循环体外，没放进每次迭代里 - 把
ctx传进闭包后，闭包内没做任何Done()或Err()检查，等于完全绕过取消控制 - 调用下游库（如
http.Client.Do、sql.DB.QueryContext）时没传当前ctx，导致 IO 层不响应取消
WithCancel / WithTimeout / WithValue 混用时的坑
它们构建的是同一棵树的不同节点，语义不能互换，混用容易让取消逻辑断裂或值查找失效。
-
context.WithCancel创建可手动触发的取消点，适合用户主动中断；context.WithTimeout自带定时器，适合 RPC 或数据库查询类操作；context.WithValue不参与取消，只存数据 —— 别用它来“开关”流程逻辑 - 同一父 ctx 上多次调用
context.WithCancel，会生成多个独立取消通道，破坏树形一致性，子节点可能收不到预期信号 - 在
WithValue派生的子 ctx 上再调WithTimeout没问题，但反过来（先 timeout 再 value）也 OK；真正危险的是把WithValue当成“配置上下文”，然后在业务逻辑里只读 value、不看ctx.Err() -
context.Background()硬编码在中间层（比如某个 service 函数里自己 new 一个），直接切断了上游取消链 —— 所有下游 goroutine 都收不到父请求的 cancel 信号
panic 后 Context 树还有效吗？
无效。Context 不捕获 panic，也不管理 goroutine 生命周期。
立即学习“go语言免费学习笔记（深入）”；
- 某层 goroutine panic 且未
recover，该 goroutine 直接退出，但它启动的子 goroutine 若持有原ctx引用，且父 ctx 尚未取消，那些子 goroutine 会继续运行 - 没有自动“级联清理”机制：cancel 信号不会因为上层 panic 而自动触发，必须靠显式调用
cancel()或超时到期 - 如果子 goroutine 在 panic 前已启动长任务（比如文件写入、流式上传），且没在关键点检查
ctx.Err()，就可能泄漏资源
真正决定取消是否生效的，从来不是 Context 树建得有多深，而是每一层是否在关键路径上主动轮询 ctx.Err() 或监听 ctx.Done() —— 尤其是循环、IO 等长耗时操作里，漏掉一次检查，就可能让整个链路失控。
