cancelctx 的 children 字段强持有子 context 指针，未及时调用 cancel() 会导致内存泄漏、timer goroutine 空转、gc 延迟及遍历开销增大；valuectx 嵌套过深会放大取消链路开销。
cancelCtx 的 children 字段会一直持有子 Context 指针
每个 cancelCtx（包括 timerCtx）内部都维护一个 children map[canceler]struct{}，用于在取消时递归通知所有子节点。这个 map 不是弱引用——只要子 Context 没被 cancel，父 Context 就会强持有它的指针。
常见错误现象：HTTP handler 中每请求调用 context.WithTimeout，但忘记 defer cancel()，导致父 Context（如 req.Context()）持续引用已退出的子 Context。
- 子 Context 关联的
*time.Timer无法 GC，定时器 goroutine 继续运行 - 父 Context（如 background 或 request context）生命周期被意外延长
- 高频请求下，
childrenmap 持续增长，内存占用线性上升
timerCtx 的定时器 goroutine 不会自动回收
context.WithTimeout 和 WithDeadline 创建的是 timerCtx，它内部启动一个 *time.Timer，并在超时后调用 cancel()。但这个 timer 的 goroutine 只有在 cancel() 被显式调用或超时触发后才会停止；如果业务提前完成却没调用 cancel()，timer 会继续跑完剩余时间。
使用场景：短耗时操作（如本地缓存查询、快速校验）配了 5s timeout，实际 50ms 就返回，但 timer 仍会空转 4.95s。
- 旧版 Go（1.14 之前）存在 timerCtx goroutine 泄漏问题，新版已修复，但未 cancel 仍会浪费调度资源
- 每个未 cancel 的
timerCtx至少额外占用 ~2KB 内存（timer 结构 + goroutine 栈） - 可通过 pprof 查看
runtime.timerprocgoroutine 数量验证是否堆积
ValueCtx 不影响级联取消，但嵌套过深会放大开销
context.WithValue 创建的 valueCtx 本身不参与取消传播（没有 children），但它会嵌套在 cancel 链中。当父 cancelCtx 调用 cancel() 时，需递归遍历整个链查找可取消节点——而 valueCtx 是“透明跳过”的，只是增加遍历深度。
容易踩的坑：在中间件中层层包裹 WithValue（如 auth → trace → metrics → reqID），形成几十层嵌套，再配合高频创建的 timeout context。
- 每次 cancel 都要从最外层
valueCtx一路向下，直到找到第一个cancelCtx - 虽单次开销小，但高并发下叠加 GC 压力和指针跳转成本
- 建议 valueCtx 层级控制在 3~5 层内，避免用它传业务参数
cancel() 调用时机比你想象的更关键
很多人以为 “只要最终调用一次 cancel() 就行”，但级联取消的内存开销取决于它被调用的**时机**，而非是否调用。
性能影响：延迟调用 cancel() 会导致子 Context 在内存中驻留更久，拖慢 GC 周期，尤其当子 Context 持有大对象（如 buffer、map）时，这些对象的回收也被一并延迟。
- 必须在业务逻辑结束后的**第一时机**调用，不是 defer 到函数末尾就安全——比如异步 goroutine 里启动了子 context，主流程 return 前就得 cancel
- HTTP handler 中，若用
http.TimeoutHandler，它内部已封装 cancel，此时外部再套一层WithTimeout并手动 cancel 就是冗余且危险的 - 测试时用
time.Sleep模拟延迟再 cancel，很容易掩盖真实泄漏，建议用runtime.GC()+pprof.WriteHeapProfile验证
