Go 的 select 语句在进入时仅对通道操作数（如
go 的 `select` 语句在进入时仅对通道操作数（如 `
在 Go 中，select 并非传统意义上的“轮询”（polling）结构。以如下常见模式为例：
for {
select {
case <p>该循环<strong>不会</strong>在每次 for 迭代中重新评估 Go 语言规范，所有通道操作数（包括接收操作的通道变量）仅在<strong>进入 select 语句时求值一次</strong>，且按源码顺序执行。这意味着：</p>
- 通道变量 ch 和 done 的地址或值只读取一次；
- 不涉及任何用户态循环检测、原子读取或条件跳转开销；
- 若无就绪通道，goroutine 将被挂起（park），交出 M/P 资源，由 runtime 在通道有数据或关闭时精准唤醒，零 CPU 占用。
这与以下伪轮询逻辑有本质区别：
// ❌ 错误类比：主动轮询，高开销且不推荐
for {
if atomic.LoadUint64(&flag) == 1 {
break
}
runtime.Gosched() // 或 time.Sleep(1ns) —— 仍属忙等
}
后者依赖高频原子读+调度让渡，消耗 CPU 并引入延迟；而 select 是事件驱动：底层通过 epoll（Linux）、kqueue（macOS）或 IOCP（Windows）等系统级等待机制实现，通道就绪即触发回调，无空转。
⚠️ 注意事项：
- select 中多个 case 具备公平随机性：当多个通道同时就绪，Go 运行时以伪随机方式选择，避免饥饿；
- 永远不要在 select 外层加 time.Sleep 来“降频”——select 本身已无开销，加 sleep 反而引入不必要延迟；
- 若需超时控制，应使用 time.After 或 time.NewTimer 配合 case
- 空 select{} 会永久阻塞；select{default:} 则立即非阻塞返回——二者均无通道求值开销。
总结：声明式等待原语，其性能优势源于 Go 运行时的深度集成设计，而非语法糖。理解这一点，是写出高效、响应式并发 Go 程序的关键基础。
