Go的select不是I/O多路复用底层实现，而是runtime层面对channel通信的调度协调机制，不涉及系统调用，仅用于channel读写选择，且多case就绪时执行顺序随机。
select 不是 I/O 多路复用的底层实现，只是 channel 协调语法
很多人一看到 “多路复用” 就联想到 epoll 或 kqueue，但 Go 的 select 完全不碰系统调用。它只在 runtime 层面对多个 channel 操作做调度协调：哪个 channel 当前可读/可写，就执行对应 case；全都不可用时，才把 goroutine 挂到这些 channel 的等待队列里。它不管理网络 fd、文件句柄或 socket，纯为 channel 通信服务。
这意味着：你不能用 select 去监听 TCP 连接就绪、文件读就绪或信号到达——那些得靠 net.Conn 自身的阻塞/非阻塞模式，或封装成 channel（比如用 conn.Read 配合 goroutine 转发到 channel）。
多个 case 同时就绪时，执行顺序是随机的
这不是 bug，是设计选择。Go 运行时会在每次进入 select 时打乱 case 的遍历顺序（pollorder），避免某个 channel 总是被优先处理导致“饥饿”。所以别依赖写在前面的 case 一定先执行。
- 如果你需要确定性顺序（比如优先处理控制信号），得靠逻辑控制：比如把控制 channel 单独拎出来，用带
default的短周期select轮询，再 fallback 到主逻辑 - 如果两个
case都能立刻执行（比如两个带缓冲的 channel 都有数据），select会随机挑一个，不会按代码顺序 - 这种随机性也意味着：测试中反复运行可能触发不同分支，要覆盖所有
case组合
default 不是超时，是“非阻塞试探”
把 default 当成超时处理，是初学者最常犯的误解。它根本没启动任何计时器，只是告诉 select:“所有 case 都不就绪？那就立刻执行 default，别等。”
- 高频轮询场景（如心跳检测）用
default+time.Sleep容易 CPU 空转，尤其在空闲时仍每毫秒跑一遍 - 真要超时，必须用
或，且注意：time.After在循环里会泄漏 timer 对象 - 更稳妥的是统一用
context.WithTimeout，让取消信号自动传播到所有支持 context 的操作（http.Client.Do、sql.QueryContext）
select 阻塞时，goroutine 会被挂起，但 channel 会加锁
当没有 default 且所有 case 都阻塞时，当前 goroutine 并不会占用 CPU，而是被 runtime 挂起，并注册进每个 case 对应 channel 的等待队列。但这个过程涉及加锁：runtime 会按固定顺序（lockorder）对所有涉及的 channel 加锁，防止死锁。
- 这意味着：如果多个 goroutine 同时对同一组 channel 做
select，它们之间会产生锁竞争，尤其在高并发下影响性能 - channel 缓冲区大小会影响是否立即就绪：满的 channel 无法接收，空的 channel 无法读取，这些状态直接决定
case是否能走通 - 关闭的 channel 仍可读（返回零值 +
ok=false），所以case v, ok := 是安全写法；但往已关闭 channel 发送会 panic
实际写的时候，最容易被忽略的是：select 本身不创建 goroutine，也不管理生命周期。它只是个同步原语，用错位置（比如在热路径里堆一堆 case）、漏掉 ok 判断、或误把 default 当定时器，都会让行为偏离预期。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
