go 的 select 本身不提供非阻塞 io 能力，仅做瞬时就绪判断；加 default 才可能非阻塞，但若外层循环无休眠或 case 求值阻塞（如同步函数作发送值），仍会卡住。

Go 的 select 本身不提供“非阻塞 IO”能力，它只是对 channel 操作做瞬时就绪判断；所谓“非阻塞”，完全依赖 default 分支是否存在——没它就一定阻塞，有它才可能跳过等待。

为什么加了 default 还是卡住了？

常见错觉：加了 default 就万事大吉。实际中仍可能卡住，原因通常是：

• select 外层被其他逻辑阻塞（比如上层 for 循环里没加 time.Sleep 或 runtime.Gosched()）
• 某个 case 表达式本身会阻塞求值（如调用一个同步阻塞函数作为发送值：ch ），这发生在 select 进入就绪检查前
• 通道已关闭但未处理 ok，导致后续误判为“有数据可读”，而实际是零值 + false，逻辑走偏

多个 case 都就绪时，为什么不是按代码顺序执行？

Go 规范明确要求：当多个 case 同时就绪，必须伪随机选择一个。这不是 bug，是防饥饿机制。

这意味着：

• 不能靠书写顺序控制优先级（比如把日志 case 写在前面就想先处理）
• 若需确定性调度，得手动加锁或改用单 channel + 类型区分（如用 struct 包裹消息类型）
• 测试时看到固定顺序，不代表生产环境也如此——底层 pollorder 是 runtime 随机生成的

无缓冲 channel 在 select 中为何总进 default？

根本原因不是“通道空”，而是“当前时刻无法完成通信”。对无缓冲 channel：

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。

下载

• 就绪条件：另一端有 goroutine 正在执行 <code>ch 并已进入发送流程（即已获取锁、已排队）
• ch 就绪条件：另一端有 goroutine 正在执行 <code> 并已等待
• 如果两端都没启动 goroutine，两个操作都不可立即完成 → 全部跳过 → 落入 default

注意：通道是否关闭、是否有缓存数据，都不影响这个判定逻辑——只看此刻能否零延迟收发。

频繁轮询导致 CPU 100% 怎么办？

default 不是免死金牌，裸写 for {} { select { ... default: } } 就是典型空转。

安全做法只有两种：

• 搭配 time.After 或 time.Tick 控制最小间隔，例如：case
• 用 runtime.Gosched() 主动让出时间片（适合调试或极低频探测）

别用 time.Sleep 直接塞在 default 里——它会让整个 select 周期变长，错过真正就绪的 channel 事件。

最易被忽略的点：select 的“就绪”是快照行为，不预测未来。哪怕你刚发完 ch ，下一毫秒执行 <code>select 也不保证能立刻收到——中间还涉及调度延迟、锁竞争、runtime 切换开销。别把它当原子信号量用。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！