否，select单case时编译器会优化，不触发runtime.selectgo；仅多case才调用selectgo函数处理调度。
select 单 case 仍触发 runtime.selectgo 调度开销
哪怕只写一个 case ，Go 编译器也不会把它优化成直接的 channel receive 操作。它依然会调用运行时的 runtime.selectgo 函数——这个函数要初始化 select 结构体、遍历所有 case（哪怕只有一个）、做随机打乱、检查通道状态、加锁、更新 goroutine 状态。这些动作本身就有固定开销，比裸写 多出约 2–5 倍的指令数和内存访问。
单 case select 无法绕过公平性机制
Go 的 select 设计上默认启用“公平调度”：每次执行都会对所有 case 随机重排序，避免某个 channel 总是被优先选中。即使只有一个 case，这个随机化逻辑（比如调用 fastrand()）仍然执行。这不是 bug，是刻意为之——因为编译器无法在运行时判断你“未来会不会加第二个 case”，所以不作特殊路径优化。
time.After 在单 case select 中放大损耗
常见错误模式：for { select { case 。这里每次循环都新建一个 time.After 返回的 channel，而该 channel 内部会启动一个独立的定时器 goroutine，并注册到全局定时器堆。频繁创建+丢弃，会导致：
- 定时器对象持续分配，GC 压力上升
- 全局定时器堆频繁 reheap，O(log n) 开销累积
- goroutine 泄漏风险（若未配合
context或显式 stop）
正确做法是复用 time.Ticker，或把 time.After 提到循环外（但注意它只能触发一次）。
真正需要 select 的场景才用它
如果你只是想等一个 channel 或一个超时，且没有并发等待需求，就别用 select：
- 等单个 channel？直接写
v := - 带超时的单 channel？用
select+time.After是合理选择，但注意time.After生命周期 - 纯周期任务？用
time.Ticker.C，不要在循环里反复调time.After
最容易被忽略的是：select 的价值在于多路分支的**非阻塞协调能力**，不是语法糖。滥用它，反而让代码更慢、更难 debug。
