select 配合 time.after 是 go 中最轻量常用超时控制方式，但需避免直接套模板导致定时器未复用或 goroutine 泄漏；正确做法是复用 timer 或用 context.withtimeout。
用 select + time.After 做超时最常用，但别直接套模板
Go 里最轻量、最常用的超时控制方式就是 select 配合 time.After。它本质是启动一个定时器，把到期的 time.Time 发到返回的 chan time.Time 上，然后让 select 等这个通道或你自己的业务通道。
常见错误是写成这样：
select {
case res := <p>问题在于：只要这个 <code>select</code> 执行一次，<code>time.After</code> 就会新建一个定时器——如果这段代码在循环里反复跑，会不断泄漏 goroutine 和定时器资源。</p>
- 正确做法：把
time.After(5 * time.Second)提前算好，复用同一个chan（尤其在 for 循环中） - 更稳妥的做法：用
time.NewTimer，手动Reset或Stop，避免意外泄漏 -
time.After适合一次性、短生命周期的超时；time.NewTimer更适合需重复使用的场景
select 默认分支不是“兜底”，而是“非阻塞立即返回”
很多人以为加个 default 就等于“超时后执行”，其实完全不是一回事。default 的语义是：所有 case 都不可达时立刻走这里，不等、不阻塞、不计时。
典型误用场景：想等 1 秒，没结果就放弃，却写了：
select {
case res := <p>这跟超时毫无关系，只是个非阻塞读。真要实现“最多等 1 秒”，必须用 <code>time.After</code> 或 <code>timer.C</code> 参与 <code>select</code>。</p>
-
default适合做“试探性读取”，比如消费缓冲通道里有没有积压数据 - 它不能替代超时逻辑，混淆这两者会导致程序行为完全偏离预期
- 如果误把
default当超时，往往表现为：请求瞬间失败，日志里全是“no result yet”，但实际后端还在跑
超时后原 goroutine 可能还在跑，得自己收尾
select 超时只影响当前协程的等待逻辑，不会自动 kill 掉正在执行 doSomething() 的 goroutine。如果那个操作是网络请求、文件读写或 CPU 密集型任务，它大概率还在后台跑着，还可能往通道发结果——而你已经不收了，造成 goroutine 泄漏或 channel panic（如果通道无缓冲且没人收）。
- 对 HTTP 请求，优先用
context.WithTimeout，让http.Client主动中断连接 - 对自定义函数，考虑接收
context.Context参数，在关键点检查ctx.Done() - 如果必须用 channel 超时，且无法改原函数，至少给发送方加个
select判断接收方是否已退出，避免死塞 - 用
defer关闭资源、用recover捕获 panic 不足以解决 goroutine 泄漏，得从协作机制上设计
time.After 在测试里容易引发 flaky test
本地跑得好好的测试，CI 上偶尔失败？很可能是用了 time.After 做断言等待。比如：
select {
case <p>问题在于：<code>time.After</code> 的精度受系统调度和 GC 影响，100ms 在高负载机器上可能变成 120ms+，导致误判超时。</p>
- 单元测试中，优先用
test helper timer（如time.NewTimer+ 手动Stop）或 mock 时间源 - 更推荐：用
sync.WaitGroup或chan struct{}显式同步，而不是靠“等多久没来就报错” - 如果必须测超时路径，把超时时间设为 1s 以上，并加注释说明这是“防御性宽松等待”，而非真实业务超时值
超时控制看着简单，真正难的是边界清理和测试稳定性——多数线上 goroutine 泄漏和 CI 失败，都藏在这几行 select 后面。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
