协程超时控制需完成“等结果+发信号+收尾”三步闭环，否则导致资源泄漏；time.after仅发送超时信号而不终止协程，若在循环内反复调用会重置倒计时、造成超时失效。
协程超时控制不是“设个时间就自动停”，而是“等结果+发信号+收尾”的三步闭环。没做全，就会泄漏。
time.After 在 select 里反复调用会失效
常见错误是把 time.After 放在循环或多次 select 内部，比如：
for i := 0; i <p>这会让每次 <code>select</code> 都重置 1 秒倒计时，总耗时哪怕 5 秒也不会触发超时。</p>
-
time.After返回的是全新通道，不可复用 - 正确做法：只调用一次，把返回的通道存为变量，全局复用
- 若需多个 goroutine 共享同一超时边界，必须提前创建
timeoutChan := time.After(1 * time.Second)
context.WithTimeout 是取消信号，不是杀进程指令
很多人以为 ctx.Done() 触发后，goroutine 就会立刻终止——其实它只是往通道发信号，后续逻辑得自己响应。
典型漏写场景：
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
go func(ctx context.Context) {
// ❌ 没检查 ctx.Done()，sleep 会照常执行完
time.Sleep(5 * time.Second)
resultCh
- 所有可能阻塞的操作（
time.Sleep、ch 、<code>、<code>http.Do）前都要加select或显式检查ctx.Err() -
http.Client要用req.WithContext(ctx)，否则超时信号进不去底层连接 -
defer cancel()必须写，否则 context 泄漏，尤其在函数提前 return 时容易漏
done 通道没缓冲，协程就卡死
用无缓冲通道通知完成，超时后主协程退出，子协程还在等 done ，永远阻塞。
示例陷阱：
done := make(chan bool) // ❌ 无缓冲
go func() { work(); done
- 最简修复：改成
done := make(chan bool, 1)，确保发送不阻塞 - 更健壮方案：结合
ctx.Done()做双重检查，避免子协程盲目发送 - 如果子协程内有多个出口（成功/失败/超时），每个出口都得确保能向
done发送或主动退出
主 goroutine 退出，子协程全被强制杀死
Go 程序结束时，不管子协程是否在运行，全部立即终止。这不是优雅退出，是粗暴截断。
这意味着：
-
time.Sleep中途被砍掉，defer不会执行 - 文件写入、数据库事务可能只写一半
- 靠
sync.WaitGroup或channel等待，是防止程序提前退出的底线操作 - 若需真正“等完再退”，必须显式同步；若接受“放弃未完成任务”，也要确保资源清理逻辑在
ctx.Done()分支里跑完
最容易被忽略的一点：超时控制和资源清理是两件事。你设了 1 秒超时，不代表 1 秒后所有状态都干净了——那得靠你自己在 case 分支里关连接、清缓存、释放锁。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
