cancelCtx.children 遍历开销随嵌套深度线性增长，取消是递归遍历而非广播；每层 cancelCtx 增加 map 遍历与 channel 关闭，valueCtx 虽不参与取消但延长遍历路径，timerCtx 未显式 cancel 会导致延迟取消假象。
cancelCtx.children 链表遍历开销随嵌套深度线性增长
取消信号不是“广播”而是“递归遍历”：当父 cancelCtx 调用 cancel() 时，它会遍历自己的 children map，对每个子节点调用其 cancel() 方法——而每个子节点又继续遍历自己的 children。这本质是深度优先的链表展开，不是 O(1) 通知。
常见错误现象：
- 5 层嵌套下，取消触发后 2–3ms 才传到最深层 goroutine（实测 pprof cpu profile 可见
context.cancelCtx.cancel占比突增） - 高频请求中 children map 元素达数千个，单次 cancel 耗时从微秒级升至毫秒级
性能影响关键点：
- 每层
cancelCtx都新增一次 map 遍历 + channel 关闭操作 -
valueCtx不参与取消，但会延长遍历路径（需跳过它才能找到下一个可取消节点） - Go 1.22+ 对 children map 做了小优化，但无法改变 O(n) 时间复杂度本质
timerCtx 未显式 cancel 导致的延迟取消假象
很多人以为 “超时到了就自动取消”，其实不然：context.WithTimeout 创建的 timerCtx 在超时那一刻才调用 cancel()；但如果业务提前完成却没调用 cancel()，那个 *time.Timer 仍会跑完剩余时间——这段时间内，即使你手动触发父 context 取消，子 timerCtx 也还没开始传播。
使用场景典型反例：
- HTTP handler 中对下游服务调用设了 10s timeout，实际 200ms 就返回，但忘记
defer cancel() - 此时该 timerCtx 的定时器仍在运行，直到 9.8s 后才触发自身 cancel，再启动向下传播
- 结果：父 context 已取消 5s，最深层 goroutine 还在跑，因为它的 timerCtx 根本没收到任何信号
验证方式：
- 用
go tool pprof -http=:8080 http://localhost:6060/debug/pprof/goroutine?debug=2查看堆积的runtime.timerproc - 检查是否大量 goroutine 卡在
select { case 却迟迟不退出
goroutine 启动时 Context 传递断裂导致传播中断
取消信号只能沿“显式传递的 context 链”传播。一旦某个 goroutine 启动时用了 context.Background() 或新构造的 context.TODO()，这条链就断了——上游取消完全不影响它。
真实调试中高频出现的断裂点：
- 闭包内直接写
go func() { ctx := context.Background(); doWork(ctx) }() - 第三方库回调中新建 context（如某些日志 hook、metrics reporter）
- 使用
sync.Pool复用结构体，但其中缓存了旧的、已失效的 context 引用
判断是否断裂的最简方法：
- 在深层 goroutine 中打印
ctx.Err()，如果一直是<nil>，说明它根本没接入取消链 - 用
fmt.Printf("ctx: %+v", ctx)看类型：若输出含valueCtx但无cancelCtx，大概率是传递中途被替换了
深层嵌套下 Done channel 接收方竞争加剧
ctx.Done() 返回的是一个只读 channel，关闭时所有监听者能同时收到信号——听起来很理想。但在 10+ 层嵌套、每层 spawn 数个 goroutine 的场景下，瞬间有几十甚至上百个 goroutine 同时从同一个 Done channel 接收，调度器要处理大量唤醒和锁竞争。
这不是 bug，但会放大延迟：
- channel 关闭本身很快，但 goroutine 从阻塞到真正执行
case 分支之间可能有可观的调度延迟 - 若这些 goroutine 还要抢同一把锁（比如统一写 error log），延迟进一步叠加
- pprof mutex profile 中常看到
runtime.chansend和runtime.selectgo占比异常高
缓解建议：
- 避免在 hot path 上让过多 goroutine 直接监听同一 parent ctx.Done()
- 对叶子任务使用独立的
WithCancel派生，把传播压力分散到多条子链 - 必要时改用
select { case 做兜底防卡死
