Go select 里 default 为什么让循环占满 CPU

会。select 里只要存在 default，当其他通信 case 暂时都不能执行时，它就会立刻进入 default，不会像没有 default 的 select 那样等待。把它放进无条件 for 后，循环就可能在“检查一次、立即返回、再检查一次”中持续自旋，最终表现为 CPU 占用升高。

修复重点不是删除所有 default，而是让空闲路径拥有明确的等待点，并让 ctx.Done() 或关闭信号始终能到达退出分支。

一、先判断是不是 default 忙轮询

最典型的风险写法是下面这样：数据通道没有值时，select 不阻塞，default 立即执行；而 for 又没有任何休眠、定时器或阻塞调用。

for {
	select {
	case item := 

如果进程空闲时 CPU 仍接近满载，先检查 default 是否只做了 continue、计数或轻量日志。日志量不大并不能证明循环在等待；真正的判断标准是空闲路径是否把控制权交还给了定时器、channel 或调度之外的等待点。

二、理解 default 为什么不等待

Go 规范对 select 的选择规则很明确：有一个或多个通信可以进行时选择其中一个；如果都不能进行但存在 default，就选择 default；没有 default 时，整个 select 会阻塞到某个通信可进行。也就是说，default 表达的是“现在不等，马上走备用分支”，不是“等待一小段时间再检查”。

因此，下面的改动会直接改变语义：去掉 default 后，数据通道为空时，循环会停在 select；加入 ctx.Done() 后，等待又多了一个可控的退出入口。

for {
	select {
	case item := 

三、用阻塞等待或定时器改掉空转

如果任务的自然节奏是“有数据才处理”，优先使用上面的阻塞 select。如果任务需要周期性检查，例如刷新状态或扫描一小批工作项，就把等待节拍写成明确的 channel，而不是用 default 逼着循环持续检查。

ticker := time.NewTicker(200 * time.Millisecond)
defer ticker.Stop() // 任务结束后释放周期控制。

for {
	select {
	case 

time.After 更适合一次性超时或短暂退避；持续循环通常用一个 time.Ticker 更容易表达节奏。无论采用哪一种，都要把 ctx.Done() 放在同一组 select 中，避免程序在等待期间无法及时结束。

四、保留非阻塞语义时补上节拍和退出

有些消费者确实需要“现在能取就取，不能取就做别的”，这时可以保留 default，但不能让它成为无限快的循环。最简单的降载方式是在空闲分支短暂休眠；如果退出延迟要求更严格，可把休眠替换成可被取消的定时器。

for {
	select {
	case item := 

这种写法的取舍是：它仍可能在空闲时占用少量 CPU，而且退出响应最多会受休眠时长影响。如果业务并不要求“立刻尝试”，应回到阻塞 select 或 Ticker 方案。还要避免在 default 中打印高频日志，否则日志系统会把空转放大成新的瓶颈。

相关问题

没有 default 的 select 会不会卡死？

它会等待通信条件；这可能是正确的阻塞，也可能暴露出没有发送者、channel 未关闭或退出信号缺失。用 ctx.Done() 或明确的关闭约定补上生命周期即可。

用 runtime.Gosched 能代替 default 的等待吗？

不能把它当作稳定节拍。让出调度机会不等于按时间等待，循环仍可能频繁运行；应根据任务语义选择阻塞 channel、Ticker 或可取消定时器。

判断这类问题时，记住一句话：default 只负责“不等待”，不负责“降低轮询频率”。真正的修复是为无数据路径设计等待，为循环设计退出。

延伸阅读：Go 语言规范中的 select 语句、time.NewTicker 文档。