context.WithTimeout 需配合 select 监听 ctx.Done() 才能中断 goroutine，否则仅创建超时上下文无效；必须在每次循环迭代及阻塞操作前检查，显式退出并调用 cancel()。
为什么 context.WithTimeout 要配合 select 和 channel 才有效
单纯调用 context.WithTimeout 不会自动中断 goroutine，它只提供一个可被取消的 ctx.Done() channel。真正起作用的是你是否在 goroutine 内监听这个 channel，并主动退出。常见错误是启动 goroutine 后就不管了，超时后 ctx.Err() 已变为 context.DeadlineExceeded，但 goroutine 仍在运行，造成资源泄漏或重复结果。
必须用 select 在关键阻塞点（如 I/O、channel receive、sleep）前检查 ctx.Done()，否则超时信号永远收不到。
- goroutine 内部必须有显式退出逻辑，比如
return或break - 不要在
for循环外只检查一次ctx.Done()；循环体里每次迭代都应检查 - 如果 goroutine 内部调用了第三方函数且不接受 context，无法靠
context中断它——这是设计局限，不是用法问题
select 里 ctx.Done() 和业务 channel 的优先级怎么设
select 是随机选择就绪 case 的，但超时控制的本质是“谁先到谁生效”。所以你要确保 ctx.Done() 和业务 channel 处于同一 select 层级，让 runtime 自行调度。不能把 ctx.Done() 放进嵌套 select 或条件判断里绕过。
典型正确写法：
select {
case result := <-ch:
// 处理结果
case <-ctx.Done():
// 清理、返回错误，如 return ctx.Err()
}
- 如果业务 channel 可能一直不发数据，而你又没监听
ctx.Done()，goroutine 就卡死 - 多个 channel 同时监听时，避免用
default消费ctx.Done()——这会让超时立即失败，失去“等待”的语义 - 若需区分超时和取消，用
errors.Is(ctx.Err(), context.DeadlineExceeded)判断
用 context.WithTimeout 启动 goroutine 的常见漏点
很多人直接传入原始 context（比如 context.Background()），然后在 goroutine 里再套一层 WithTimeout，这会导致超时计时从 goroutine 启动才开始，而非从主流程发起时刻开始。正确做法是在启动前就创建带超时的子 context。
- ❌ 错误：在 goroutine 内调用
context.WithTimeout(context.Background(), time.Second) - ✅ 正确：在
go func(ctx context.Context) { ... }(ctx)前，先ctx, cancel := context.WithTimeout(parentCtx, time.Second) - 记得调用
cancel()—— 即使超时触发了，也要显式释放资源，尤其当 context 被复用或嵌套时 - 如果 goroutine 启动后立刻 panic，
cancel()可能没执行，建议用defer cancel()包裹整个 goroutine 函数体
超时后 goroutine 真的停了吗？如何验证是否残留
Go 没有强制终止 goroutine 的机制，ctx.Done() 只是通知，是否响应全看代码。所谓“超时控制成功”，是指 goroutine 主动退出、不再占用 CPU、不再往 channel 发送数据、不再持有锁或文件句柄。
验证方法：
- 用
runtime.NumGoroutine()在超时前后对比，看是否回落 - 在 goroutine 退出前加日志，确认
<-ctx.Done()分支被执行 - 若 goroutine 内有长循环且未检查
ctx，即使超时了也会继续跑满 CPU —— 这时必须插入if ctx.Err() != nil { return } - 注意：channel send 操作在接收方已关闭时会 panic，超时处理中要确保发送前检查
ctx.Err()，否则可能 panic 掩盖超时逻辑
最易被忽略的是：超时后 goroutine 虽退出，但其启动的子 goroutine 或 defer 函数仍可能运行。所有清理动作必须放在同一 goroutine 内完成，不能依赖外部协程回收。
