context.WithCancel的取消信号能穿透任意深度的goroutine层级，但前提是每层都正确传递ctx并用select监听ctx.Done()；漏掉任一层监听或误用阻塞操作（如time.Sleep）将导致信号失效。
context.WithCancel 的取消信号能穿透多深的 goroutine 层级？
能，但前提是每层都正确传递并监听 ctx.Done()。Go 的 context 取消机制本身不“自动传播”，它只提供一个被关闭的 chan struct{}；协程是否响应、何时响应、是否阻塞在非 select 操作上，全由你控制。
常见误判是认为“只要父 context 被 cancel，所有子 goroutine 就立刻停止”——实际中，哪怕只漏掉一层 select 判断，或用了 time.Sleep 替代 select 等待，信号就彻底失效。
- 协程启动时必须接收
ctx参数，不能闭包捕获外部 context 变量（易导致生命周期错乱） - 所有可能阻塞的操作（如
http.Get、time.Sleep、ch 、）都应包裹在select中，与ctx.Done()并列 - 深层子协程（比如 goroutine 启动 goroutine）仍需显式传入 context，不能依赖“祖父 ctx 自动生效”
为什么用 time.Sleep 代替 select 会导致取消失效？
因为 time.Sleep 是同步阻塞，期间完全不检查 context 状态。即使父 context 已被 cancel，goroutine 仍会睡满指定时间才继续执行，错过所有取消时机。
对比之下，select 是 Go 原生支持 context 协作的唯一可靠入口点。只要 ctx.Done() 在 select 中且未被其他 case 先触发，它就能立即返回。
database/sql
- 检查每一层 goroutine 的启动函数签名，确认
ctx context.Context是第一个参数 - 避免在 goroutine 内部重新
context.WithCancel或context.WithTimeout，除非你明确需要独立生命周期——否则应直接复用上游传入的 ctx - 对第三方调用，优先选用带
Context后缀的方法（如client.Do(req.WithContext(ctx))），而非无参版本
如何写一个最小可验证的可靠性测试？
核心是构造“延迟响应 + 提前 cancel”组合，并观察最深层 goroutine 是否在预期时间内退出。不要依赖日志顺序，而要靠通道或 sync.WaitGroup 显式同步结果。
关键点在于：让最内层 goroutine 在收到 cancel 后向主 goroutine 发送信号，主 goroutine 用带超时的 select 等待该信号——如果超时发生，说明取消失败。
func TestDeepCancel(t *testing.T) {
ctx, cancel := context.WithTimeout(context.Background(), 100*time.Millisecond)
defer cancel()
<pre class="brush:php;toolbar:false;">done := make(chan struct{})
go func() {
// 第一层
go func() {
// 第二层
go func() {
// 第三层：必须 select 监听 ctx.Done()
select {
case <p>}
</p>
真正难测的不是“能否取消”，而是“是否在任意路径下都取消”。比如某条错误分支里忘了 select，或 panic 后 defer 没来得及清理资源——这些都要靠代码审查和覆盖关键路径的测试用例补全。
