select 配合 time.After 实现超时最常用但有坑：time.After 会创建新定时器，若长期不触发将导致定时器无法 GC 而泄漏；正确做法是优先用 time.NewTimer 并及时调用 Stop()。
select 配合 time.After 实现超时最常用但有坑
Go 里用 select 做超时控制，最直觉写法是加一个 time.After 分支。但它会创建新定时器，如果超时分支长期不触发（比如业务逻辑卡住），定时器对象无法被 GC，可能累积泄漏。
- 正确做法优先用
time.NewTimer，用完立刻timer.Stop()，避免资源滞留 - 若只用一次且确定不会重复执行，
time.After可接受；但别在循环里无节制调用 -
time.After返回的是<-chan time.Time，不能重复读取，第二次读会永久阻塞
select 默认分支导致超时失效的典型场景
有人把超时逻辑写成 select { case ，以为 default 就是“超时”，其实不是——default 是非阻塞立即返回，和时间无关，它根本没启动任何计时。
- 真正超时必须依赖一个可接收的 channel，比如
time.After(500 * time.Millisecond) - default 适合做“快速试探”，比如检查 channel 是否就绪，但不能替代超时控制
- 如果误用 default 当超时，在高并发下可能瞬间刷出大量空转，CPU 拉满
context.WithTimeout 是更安全的超时封装方式
直接操作 select + time.Timer 容易漏掉 Stop 或误关 channel，而 context.WithTimeout 把生命周期管理收束到 context 里，更可靠。
-
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)后，所有支持 context 的 API（如http.Client.Do、sql.DB.QueryContext）能自动响应取消 - 手动参与
select时，用case 替代 <code>time.After，还能统一处理取消原因（超时 or 主动 cancel） - 记得调用
cancel()，否则底层 timer 和 goroutine 不释放，尤其在函数提前 return 时容易遗漏
IO 多路复用中 select 的真实限制
Go 的 select 不是 epoll/kqueue 封装，它只是语言层的 channel 协调机制，不涉及系统级 IO 复用。所谓“Go 的 IO 多路复用”其实是 runtime 网络轮询器（netpoll）在底层做的，对用户透明。
立即学习“go语言免费学习笔记（深入）”；
-
select本身不提升 IO 性能，它只解决“多个 channel 同时等待时选哪个”的问题 - 不要指望靠堆砌
select分支来“并发处理更多连接”，连接数瓶颈在文件描述符、goroutine 调度和内存，不在select写法 - 单个
select最多监听约 65536 个 channel（受编译器常量限制），但实际远达不到这个数——分支一多，编译慢、运行时调度开销也明显上升
实际写服务时，超时控制往往混着 channel 关闭、context 取消、错误重试一起发生，select 分支里要小心判空、检查 ok、及时 break 或 return，不然容易陷入假死或 panic。
