Go中无内置“超时控制函数”，必须用select配合time.After或time.NewTimer实现协作式等待；time.Sleep会彻底阻塞goroutine，无法响应通道或取消信号，而select可并行监听业务channel与timer通道，确保及时响应。
Go 里没有叫“超时控制函数”的内置函数，select + time.After 或 time.NewTimer 才是实际干活的组合；它不是封装好的黑盒，而是靠 channel 通信机制实现的协作式等待。
为什么不能只写 time.Sleep 然后判断？
time.Sleep 会彻底挂起当前 goroutine，期间无法响应任何信号（比如通道数据到达、取消请求），等于把控制权交出去了。而真实场景中，你往往需要“一边等结果，一边等时间”，两者是并行关系，不是先后顺序。
- 用
time.Sleep模拟超时，只能在 sleep 完后再去检查——已经错过结果送达的时机 -
select是唯一能同时监听多个 channel（包括 timer 通道）的语法结构 - timer 通道本质就是个“倒计时完成就发一个
time.Time值”的 channel，和业务 channel 地位完全平等
time.After 和 time.NewTimer 怎么选？
time.After 简单直接，但每次调用都新建一个不可复用的 timer；time.NewTimer 需手动管理生命周期，适合高频或需提前取消的场景。
- 一次性等待（如单次 HTTP 请求超时）：用
time.After(5 * time.Second)最清晰 - 循环中反复等待（如心跳检测、重试逻辑）：必须用
time.NewTimer，并在每次 select 后调用timer.Stop() - 用户可能中途取消操作（比如 UI 点了“停止”）：必须用
time.NewTimer，因为time.After无法 Stop - 漏掉
timer.Stop()会导致 timer 对象长期驻留内存，尤其在短周期循环里容易积压
select 中漏掉 default 或误读 timer.C 会怎样？
常见错误不是语法报错，而是行为异常或资源泄漏：
立即学习“go语言免费学习笔记（深入）”；
- 把
<-timer.C写在select外面单独读取：会阻塞，失去超时意义 - select 里用了
time.After，但没消费其值（比如只写case <-time.After(...):），该 timer 实例无法被 GC 回收 - 加了
default却没意识到它会让 select 立即返回——这不再是“等待”，而是“轮询”，CPU 占用飙升 - 多个 case 同时就绪时，select 随机选一个执行，不保证顺序；别依赖 case 的书写顺序
最易被忽略的一点：超时本身不是目的，而是为了触发后续清理动作。比如 timer 触发后，你要关掉正在跑的 goroutine、关闭未读完的连接、释放持有的锁——这些都不在 select 语法里，得你自己写。
