context.WithCancel生成的子context会立即感知父cancel：父调用cancel()时同步关闭自身Done通道并遍历children map关闭所有子Done通道，传播无调度延迟，所谓“延迟”实为业务代码未及时响应Done信号。
context.WithCancel 生成的子 context 不会立即感知父 cancel
调用 context.WithCancel(parent) 创建子 context 后，子节点对取消信号的响应不是即时的——它依赖于父 context 的 done channel 是否已关闭，而该 channel 只在父调用 cancel() 时才被关闭。这意味着：如果父 context 是从另一个 WithCancel 创建的，它的 done channel 关闭动作需逐层向上触发，但实际传播是同步的（无队列、无调度延迟），真正造成“延迟感”的通常是用户代码中对 <ctx.done></ctx.done> 的轮询时机或阻塞读取方式。
- 常见错误现象：
select中监听ctx.Done()却长时间未退出，误以为是 context 传播慢，实则是当前 goroutine 正卡在某个不响应 cancel 的阻塞操作（如无缓冲 channel send、未设 timeout 的 HTTP 请求） - 使用场景：微服务间 RPC 调用链中，上游提前 cancel，下游应尽快中止；此时若下游在
http.Client.Do中未传入该 ctx，或用了自定义 transport 且未适配 context，就会“无视”取消信号 - 关键点：
context.cancelCtx内部的children是 map 类型，遍历并关闭子donechannel 是同步 for 循环，不涉及 goroutine 或调度器介入，因此传播本身无可观测延迟（纳秒级）
为什么 select { case
这不是 context 传播的问题，而是 Go 运行时对 channel 操作的调度语义导致的。当多个 case 准备就绪时，select 随机选择一个；但如果 ctx.Done() 对应的 channel 已关闭，其 case 永远就绪，理应立刻命中——除非你没在关键路径上检查它。
- 典型陷阱：把
select放在循环体外，或只在某次 I/O 后才检查一次ctx.Done()，导致取消信号被“漏过” - 正确姿势：所有可能长期运行的逻辑（尤其是循环体、网络读写、定时等待）都应在每次迭代开头或关键阻塞前插入
select判断 - 参数差异注意：
time.AfterFunc或time.Sleep不响应 context，必须改用time.After+select，或封装为time.AfterFunc的 cancel-aware 版本
WithTimeout/WithDeadline 的底层 cancel 触发时机
context.WithTimeout 和 context.WithDeadline 底层都基于 timerCtx，其 cancel 行为由一个独立 goroutine 启动的 time.Timer 控制。这个 timer 在到期时调用 cancel()，进而同步关闭自身 done channel 并通知所有子节点。
- 性能影响：每个
timerCtx启动一个time.Timer，频繁创建（如每毫秒新建一个 WithTimeout）会增加 timer heap 压力，可能拖慢调度；建议复用或改用手动控制的 ticker + 显式 cancel - 兼容性坑：
time.Timer.Stop()并不保证 timer 已停止（可能刚触发 callback），所以timerCtx.cancel()内部做了 double-check，这也是为什么多次调用子 context 的 cancel 是安全的 - 容易忽略的细节：系统时间跳变（如 NTP 校正）可能导致
timerCtx提前或延后触发；生产环境应避免依赖绝对 deadline，优先用相对 timeout
跨 goroutine 传递 context 时的 cancel 可见性边界
context 值本身是线程安全的，但它的取消状态变更（即 done channel 关闭）对其他 goroutine 是可见的——只要它们通过相同变量引用该 context 实例。问题往往出在“副本”或“重赋值”上。
- 常见错误：在 goroutine 内部重新声明
ctx := ctx，或传参时被中间函数无意修改（如某些日志 wrapper 返回新 context 但未继承 cancel 树） - 验证方法：打印
fmt.Printf("%p", ctx.Done())，确保父子 goroutine 中拿到的是同一个 channel 地址 - 真实案例：gRPC 客户端拦截器中若用
ctx = context.WithValue(...)但忘了调用原始invoker时传入该 ctx，会导致下游完全收不到 cancel 信号
真正的传播延迟几乎不存在，所谓“延迟”99% 来自业务代码未及时响应 Done channel，或是误以为 cancel 能中断正在执行的系统调用（比如 os.Read 不受 context 控制，必须配合 net.Conn.SetReadDeadline 等机制）。别怪 context，先查你的 select 和阻塞点。
