Go 通道select 默认分支导致忙等怎么办

Go 里把 select 放进无限循环时，如果同时写了 default，很容易出现“通道没有消息，但 CPU 占用持续升高”的忙等。原因不是 channel 失效，而是 default 明确要求这次选择不能等待：只要其他通信此刻都不能执行，就立即返回默认分支，然后循环马上再次进入 select。

需要等待消息时，删掉 default，让 goroutine 阻塞在 channel 或取消信号上；需要周期性检查时，用 time.Ticker 表达间隔；只有确实要“现在有就拿、没有马上返回”时，才保留一次性的非阻塞 select。

官方文档：https://go.dev/ref/spec#Select_statements、https://go.dev/blog/concurrency-timeouts。下面用一个小型任务消费者把这几个边界拆开。

先看一个会忙等的最小消费者

假设 worker 负责从 jobs 接收任务。下面的写法看起来像“没有任务就继续检查”，但它没有任何等待点：

package main

func consume(jobs 

当 jobs 暂时没有值时，接收 case 不能执行，default 就会被选中。它不会像没有 default 的 select 那样挂起当前 goroutine，因此循环会以尽可能快的速度反复判断。这个循环里即使没有业务任务，也有持续的调度和判断成本。

需要等任务时，直接移除 default

如果这个 worker 的职责就是“有任务才处理”，最小修复不是加一个更短的 Sleep，而是让选择语句恢复等待语义。再加入 context.Done()，就能在没有任务时休眠，并且在服务关闭时及时退出：

package main

import "context"

func consume(ctx context.Context, jobs 

这里没有 default。当 jobs 和 ctx.Done() 都没有就绪事件时，select 会等待；有任务就处理任务，收到取消信号就退出。这个版本把“等待”交给 channel 机制，把“退出”交给 context，业务循环本身不再需要猜一个睡眠时长。

需要定期做事时，用 ticker 代替空转

有些 worker 不只是收任务，还要每隔一段时间刷新统计、清理过期状态或发送心跳。这时不能简单删除所有额外分支，但也不应该用 default 驱动循环。把周期性动作放到 ticker case，等待点仍然由 select 提供：

package main

import (
	"context"
	"time"
)

func runWorker(ctx context.Context, jobs 

NewTicker 把“多久检查一次”变成显式配置。间隔应该根据业务新鲜度和成本决定，不是为了掩盖忙等而随手写一个极短的值；如果任务到达本身没有时间要求，阻塞等待通常更简单。

收尾时处理取消和关闭通道

忙等还有一个容易被忽略的来源：接收已经关闭的 channel。关闭后的 channel 接收会立即返回零值；如果代码不检查第二个返回值 ok，循环可能一直把这个零值当成新任务处理。对可选的 channel，还可以在关闭后把变量设为 nil，让它从后续 select 中失效。

package main

import (
	"context"
	"time"
)

func serve(ctx context.Context, jobs 

如果 channel 是必需输入，收到 ok == false 后直接 return 更清楚；只有还要继续监听其他分支时，才把已关闭的 channel 置为 nil。不要把关闭后的零值继续送入业务处理，也不要在已经结束的 worker 中保留一个永远可选中的关闭通道。

只有需要立即返回时，才保留非阻塞探测

default 本身没有错，它适合封装成“一次尝试”：现在能收到就返回任务，现在没有就返回 false。关键是不要再用无限循环把这个一次性探测变成无间隔轮询。

package main

func tryReceive(jobs 

调用方可以在一次 HTTP 请求、一次事件回调或已有调度器的单个 tick 中调用 tryReceive。如果调用方没有外层节奏，应该改用前面的阻塞 worker 或 ticker worker，而不是在这里再套一层 for { tryReceive(...) }。

按症状选择修复方式

可以用这份清单复查现有代码：default 是否位于无限循环内、没有通信就绪时是否存在真正的等待点、是否监听了取消信号、接收是否检查了 ok、ticker 是否在退出路径停止。如果只是加 runtime.Gosched() 或固定 Sleep 后 CPU 降了，也不代表语义已经正确：前者仍是忙循环，后者则把响应延迟和周期精度交给了一个难以解释的常量。

几个容易混淆的问题

select 的 case 是随机执行的吗？

当多个通信都可以执行时，Go 规范规定从可执行通信中做均匀的伪随机选择；当没有通信可执行且存在 default 时，才选择 default。所以问题不在 case 的排列顺序，而在于循环是否需要等待。

把 default 改成 time.Sleep 就可以了吗？

如果需求是等待任务，不建议这样改。睡眠会引入固定延迟，任务到达后也不能立即唤醒；如果需求确实是定期任务，应使用 ticker，让周期和资源释放语义更明确。

关闭 channel 后为什么还会重复进入接收分支？

关闭后的 channel 不再接收新值，但接收操作会立即完成并返回元素类型的零值，同时 ok 为 false。循环如果忽略 ok，就会把这个已关闭分支当成一直就绪，从而再次形成空转。

归根结底，default 表达的是“现在不等”，而不是“稍后再试”。先确定消费者需要阻塞、定期处理还是立即探测，再让 select 的结构匹配这个意图，忙等通常就能在根上消失。