go 中 select 本身不支持超时，需借助 time.after 或 context.withtimeout；很多人初学时直接写 select + case，忽略超时处理机制。
Go 中 select 本身不支持超时，得靠 time.After 或 context.WithTimeout
很多人一上来就写 select + case ，发现加了 <code>default 是非阻塞，但没法等 5 秒就放弃——select 没内置 timeout 参数。真正可控的等待，必须引入时间信号源。
两种主流做法：
-
time.After(d)最轻量，适合单次、简单超时（比如等一个 channel 在 3 秒内吐数据） -
context.WithTimeout(ctx, d)更适合有取消传播需求的场景（比如 HTTP 请求链路中下游也要响应上游取消）
注意：time.After 每次调用都会启一个 goroutine，高频循环里别直接写 time.After(100 * time.Millisecond)，容易积压 timer。
select + time.After 的典型误用：超时后 channel 还在发数据，导致 goroutine 泄漏
常见错误是启动一个异步操作（比如 go func() { ch select 等结果或超时。一旦超时，doWork() 仍在后台跑，结果最终写进 ch，但没人收——channel 阻塞，goroutine 卡住。
立即学习“go语言免费学习笔记（深入）”；
正确姿势是让工作函数能感知退出：
- 传入
ctx.Done()，在关键点 select 检查是否被取消 - 用带缓冲的 channel（如
ch := make(chan Result, 1)），避免发送端阻塞 - 超时分支里不光要 break，还要考虑是否需要关 channel 或重置状态
示例片段：
ch := make(chan string, 1) go func() { ch <- slowFetch() }() select { case result := <-ch: fmt.Println(result) case <-time.After(2 * time.Second): fmt.Println("timeout") }HTTP 请求用 context.WithTimeout 才真正可靠
http.Client 自身有 Timeout 字段，但它只控制整个请求生命周期（DNS + 连接 + 写请求 + 读响应），且无法中途取消。而 context.WithTimeout 能穿透到底层连接、TLS 握手、甚至流式响应的读取过程。
关键点：
- 必须把 context 传给
req.WithContext(ctx)，不是只传给client.Do() -
client.Timeout和 context 超时同时设时，以先触发者为准，但 context 可被主动取消，更灵活 - 超时后，
resp.Body.Close()仍需调用，否则底层连接可能不释放
错误写法：client.Do(req)；正确写法：client.Do(req.WithContext(ctx))。
别在 select 外层套 for 循环还复用同一个 time.After
下面这段代码会出问题：
timer := time.After(1 * time.Second) for { select { case <-ch: ... case <-timer: // 第一次命中后，timer 已过期，后续永远走这个分支 } }原因：time.After 返回的是单次触发的 ，不能重用。每次循环都要新调用 <code>time.After，或者改用 time.NewTimer 并在超时后 Reset()。
更安全的循环超时写法：
- 循环内写
case （适合低频） - 或显式管理 timer：
t := time.NewTimer(1 * time.Second); defer t.Stop()，超时后t.Reset(1 * time.Second)
高频轮询场景下，后者能减少对象分配和 timer 管理开销。
超时逻辑看着简单，但 channel 生命周期、context 传播、timer 复用这三块最容易埋雷。写完别只测“正常路径”，一定要模拟慢依赖、中断信号、连续超时这些 case。