go 的 select 是 channel 多路协调器，非系统 i/o 多路复用；仅监听 channel 就绪状态，i/o 需封装为 channel；default 是非阻塞试探而非超时，超时须用 time.after 等定时 channel。
Go 语言中 select 并不直接操作底层文件描述符，也不是系统级 I/O 多路复用（如 epoll）的封装，而是专为 channel 通信设计的协调语法。它真正解决的是“多个 goroutine 间如何安全、高效地响应多个 channel 状态变化”这一问题。
select 不是系统 select，而是 channel 多路协调器
它不能监听网络 socket、文件或定时器本身，只能监听 channel 的发送/接收是否就绪。所有 I/O 操作（如 HTTP 请求、数据库查询、文件读写）必须先封装成 channel 通信模式，再交由 select 调度。
- 例如：用
http.Get启动请求后，把结果发到 channel；用time.After返回一个只读 channel；用ctx.Done()获取关闭通知 channel - 真正的系统级 I/O 多路复用由 Go 运行时 netpoller 自动完成，对开发者透明——你写的 select 只是站在上层“消费”这些就绪事件
- 混淆二者会导致误判性能瓶颈：想靠堆砌 select case 提升并发连接数，实际会因 goroutine 调度和内存开销反而变慢
default 不是超时，是立即返回的非阻塞试探
把 default 当作“超时分支”是高频误用。它不启动任何计时器，只表示“此刻所有 case 都不可执行，别等了，直接走我”。
- 适合场景：轮询检查 channel 是否有数据（如心跳探测、状态快照），但需配合
time.Sleep或time.Tick控制频率，否则空转拉满 CPU - 危险写法：
for { select { default: doWork() } }——doWork()会被无限调用 - 正确超时：必须用可接收的定时 channel，如
case （仅限单次）或更推荐的 <code>case + <code>timer.Stop()
多个 case 就绪时执行顺序完全随机
哪怕把退出通道 quitCh 写在第一个 case，只要它与数据通道 dataCh 在判定瞬间同时就绪，Go 就可能选 dataCh 执行。这是防饥饿机制，不是 bug。
- 需要强优先级（如必须先响应取消）？拆成嵌套 select：
select { case ，再进主循环 - 或改用
if select { case 做前置快速检测 - 调试技巧：多跑几次，输出顺序跳变，说明已被随机调度影响
case 表达式在 select 开始前就求值
写 case ，不是等到超时才调 <code>expensiveFunc()，而是在进入 select 的那一刹那就执行——若它含 http.Get 或 time.Sleep，整个 goroutine 会卡住不动。
- 耗时计算必须提到 select 外：
timeout := expensiveFunc(); select { case - 避免内存泄漏：
time.After每次都新建 timer，长期不触发则无法 GC；高频场景务必用time.NewTimer+timer.Stop() - 最省心方案：统一用
context.WithTimeout，让取消信号自然流入http.Client.Do、sql.DB.QueryContext等原生支持 context 的 API
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
