Done信号非即时广播而是逐层递归触发，延迟随嵌套深度线性增长；cancelCtx.children遍历是性能瓶颈，每次父cancel()调用均需遍历children map并对每个子cancelCtx递归调用cancel()，属深度优先递归而非并发通知。
Done 信号不是即时广播，而是逐层递归触发，延迟随嵌套深度线性增长
cancelCtx.children 遍历是性能瓶颈
每次父 cancel() 被调用，都会遍历自己的 children map，对每个子 cancelCtx 再调用其 cancel() —— 这是深度优先递归，不是并发通知。
常见错误现象：
- 5 层嵌套下，从顶层
cancel()到最深层 goroutine 收到，实测延迟达 2–3ms - 高频服务中 children map 元素上千时，单次 cancel 耗时从微秒级跳至毫秒级
关键点：
- 每层
cancelCtx增加一次 map 遍历 + 一次close(done)操作 -
valueCtx不参与取消，但会延长遍历路径（需跳过它才能找到下一个可取消节点） - Go 1.22+ 对 children map 做了小优化（如避免重复扩容），但无法改变 O(n) 时间复杂度本质
timerCtx 未显式 cancel 会造成“假延迟”
很多人误以为 context.WithTimeout 创建的 timerCtx 会在超时那一刻“立刻传播取消”，其实它只在内部 *time.Timer 触发时才调用自身 cancel()；如果业务提前完成却没调用 cancel()，定时器仍在跑。
典型反例：
- HTTP handler 中设了 10s timeout，实际 200ms 就返回，但忘记
defer cancel() - 该 timerCtx 的定时器继续运行 9.8s，期间即使父 context 已取消，它也不会向下传播
验证方式：
- 用
go tool pprof -http=:8080 http://localhost:6060/debug/pprof/goroutine?debug=2查看堆积的runtime.timerproc - 检查是否有大量 goroutine 卡在
select { case 却迟迟不退出
Context 传递断裂直接中断信号链
取消信号只能沿“显式传递的 context 链”传播。一旦某个 goroutine 启动时用了 context.Background() 或 context.TODO()，这条链就断了——上游取消完全不影响它。
常见场景：
- 在中间函数里漏传
ctx，改用context.Background()新起 goroutine - RPC client 封装层未把入参
ctx透传到底层http.NewRequestWithContext() - 数据库驱动初始化时硬编码
context.Background()，导致 query 超时后连接仍被占用
这类问题不会报错，但会导致资源泄漏和响应延迟不可控。
真正影响延迟的往往不是“要不要用 context”，而是每一层是否都严格遵循“接收 → 透传 → 显式 cancel”三原则；尤其是 timerCtx 的 defer cancel() 和 valueCtx 的“不打断链路”这两处，最容易被忽略。
