select 是 go 独立的运行时调度机制，其执行取决于 channel 通信就绪状态而非代码顺序；所有 case 一次性求值，无 default 时 goroutine 挂起并注册到各 channel 等待队列，多 case 就绪时伪随机选择以避免饥饿。
select 不是语法糖，也不是 switch 的变体；它是一套独立的运行时调度机制，必须通过 channel 通信行为反推其逻辑，靠“读代码”学不会。
为什么直接写 select 永远搞不清它在做什么
很多人写完一个带 default 的 select，看到输出就以为“非阻塞”生效了，但其实没触发任何 channel 通信；也有人删掉 default 后程序卡住，却不知道是哪个 case 在等谁——因为 select 的行为不取决于代码顺序，而取决于当前 goroutine 和所有涉及 channel 的另一端协程是否处于可通信状态。
-
select所有case表达式（包括 channel 和发送值）会在进入select块时**一次性求值**，不阻塞 - 真正决定执行路径的是“就绪检查”：接收操作要求 channel 有数据 且 对端有 goroutine 等待发送（无缓冲）或缓冲未满（有缓冲）；发送同理
- 没有
default时，select会把当前 goroutine 挂起，并注册到所有 case 对应 channel 的等待队列中——不是轮询，是真挂起
select 中多个 case 同时就绪时，为什么不能预测执行哪一个
这不是 bug，是设计：Go 运行时用伪随机数打乱 case 遍历顺序（pollorder），再按 channel 地址排序加锁（lockorder）避免死锁。目的是防止某个 channel 总是被优先选中，造成“饥饿”。
- 即使你把
写在第一个 <code>case，也不能保证它先执行 - 两个无缓冲 channel 都有 goroutine 在对端等待收/发，它们就是“同时就绪”，
select必然随机挑一个 - 想验证？用
runtime.Gosched()在每个 case 分支末尾插入，反复跑几次，观察输出顺序变化
为什么 time.After 能进 select，但 fmt.Scanln 不行
因为 select 只接受 channel 操作，time.After 返回 ，而 <code>fmt.Scanln 是同步函数调用——编译器会直接报错：select case must be receive, send or assign recv。
- 标准输入、文件读取、HTTP 响应体等非 channel I/O，必须用 goroutine 包一层，转成 channel 事件才能进
select - 错误写法：
case line, _ := fmt.Scanln():→ 编译失败 - 正确模式：
go func() { line, _ := reader.ReadString('\n'); ch ，然后 <code>case line :=
最容易被忽略的坑：select 里重复使用同一个 channel 变量
看似无害的写法，可能引发 panic 或静默失效：
- 在多个
case中混用同一 channel 的发送和接收（比如case ch 和 <code>case ），如果该 channel 是无缓冲的，<code>select会因两端 goroutine 未就位而永远等不到就绪 - 更隐蔽的是：把 channel 作为参数传入函数，在函数内建
select，但调用方已 close 该 channel —— 此时接收操作仍就绪（返回零值+false），但发送操作会 panic - 调试建议：对关键 channel 加日志，记录
len(ch)、cap(ch)和是否 closed，别只看select本身
真正理解 select 不靠背规则，而靠制造失败：故意让 channel 为空、关闭、不配对 goroutine，观察它卡在哪一步、default 是否触发、panic 发生在哪个 case——只有破坏，才能看清机制。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
