context.WithCancel 的取消信号对子协程100%可靠，前提是子协程正确监听同一ctx.Done()通道；常见失效原因：传入Background/TOD0上下文，或未用select监听Done而用if判断Err。
context.WithCancel 的取消信号对子协程 100% 可靠，前提是每个子协程都正确监听了同一个 ctx.Done() 通道。它不是“尽力而为”，而是 Go 运行时级的同步广播机制：cancel() 一调，所有已订阅该上下文的 ctx.Done() 立即关闭，无延迟、无丢失。但可靠性崩塌点往往不在机制本身，而在使用方式。
为什么子协程收不到 cancel 信号
常见现象是调用 cancel() 后，子协程仍在运行，日志没输出，CPU 占用不降。根本原因几乎总是以下之一：
- 子协程启动时传入的是
context.Background()或context.TODO()，它们的Done()永远不会关闭 - 子协程里用了
if ctx.Err() != nil而非select { case ，导致只检查了一次就跳过，后续信号完全被忽略 - 协程启动后，父协程没保存好
cancel函数（比如定义在 if 分支里），导致后续根本没法调用 - 多个 goroutine 并发调用同一个
cancel()是安全的，但若误把cancel函数传给了子协程，子协程又自行调用——这虽不 panic，但破坏了“父控子”的职责边界，容易引发竞态或重复清理
多层派生时信号是否穿透所有层级
是的，只要每层都用 context.WithCancel(ctx) 或 context.WithTimeout(ctx, ...) 派生，取消就会自动向下传播。不需要手动“转发”或“广播”。
关键细节：
- 派生必须基于上一级的
ctx，不能跳级（比如从ctx1派生ctx2，再用context.Background()派生ctx3，那么ctx3就脱离了树） -
WithValue不影响取消传播，它只是附加数据；但滥用WithValue可能掩盖真正需要传递的ctx，间接导致漏传 - 子协程内若再派生新上下文（如加超时），应基于当前
ctx，而非重新用Background()—— 否则新派生的上下文就收不到原始取消信号
cancel() 调用后子协程仍卡在阻塞调用中
这是最典型的“看似失效”场景：子协程卡在 http.Get、time.Sleep、ch 或数据库查询上，<code>select 没机会执行。
解决办法不是“等它自己醒来”，而是让阻塞操作本身支持上下文：
- HTTP 请求必须用
http.NewRequestWithContext(ctx, ...)+client.Do(req)，否则Get完全无视 context - 数据库操作要传
ctx给db.QueryContext、tx.ExecContext等方法，标准库database/sql已全面支持 - 自定义阻塞操作（如轮询、文件读取）需在内部定期检查
ctx.Done()，不能依赖外部 select -
time.Sleep应换成time.AfterFunc或用select+time.After，并把ctx.Done()作为 case 之一
真正的可靠性陷阱不在 context.WithCancel 本身，而在于「是否让每个阻塞点都成为取消信号的接收端」。只要所有协程入口和所有可能阻塞的位置都接入了 ctx.Done()，那 cancel 就是原子、即时、全覆盖的。
