select 的 default 分支如何避免忙等

如果把 select 的 default 放进一个没有退出条件的紧循环，最容易出现的结果就是忙等：没有任务时循环不会阻塞，而是立刻执行 default，随后马上开始下一轮。解决方式不是给 default 增加更多日志，而是根据场景选择真正的等待点：能阻塞就删除 default，需要非阻塞探测时就配合 time.Ticker 或退避，并给循环保留取消路径。

一句话判断：default 适合“现在就检查一次”，不适合代替等待。只要它位于高速循环里，就必须给下一次检查安排节奏，或者改成阻塞式 select。

官方资料：https://go.dev/ref/spec#Select_statements

先看清 default 的实际行为

Go 语言规范规定，select 进入后会先计算各个通信操作；如果有通信可以继续，就选择其中一个；如果没有通信但存在 default，就直接选择 default；只有没有可继续通信且没有 default 时，select 才会阻塞。

所以，下面的代码不是“等待任务”，而是“不断询问任务现在有没有到达”：

jobs := make(chan string)

for {
	select {
	case job := 

当 jobs 暂时没有可接收的数据时，循环不会把 goroutine 挂起。它会反复走 default，直到任务到来或程序被其它逻辑停止。这里的“忙等”不是 select 本身出错，而是“立即返回”与“无限重试”组合后的结果。

需要非阻塞探测时，给循环加节奏

有些循环确实不能一直阻塞，例如还要周期性刷新状态、检查其它资源或执行一次轻量维护。这时可以保留 default，但不要让它直接回到下一轮，而是让循环由一个明确的时间节拍驱动。time.Ticker 比在循环里反复创建 time.After 更适合长期运行的周期任务。

ticker := time.NewTicker(20 * time.Millisecond)
defer ticker.Stop() // 退出函数时释放 ticker 关联的资源

for {
	select {
	case job := 

这个写法已经没有 default：有任务时立即处理，没有任务时等到 ticker 到点再做周期工作。若你的“探测”必须保持非阻塞，可以把探测动作放在 tick 分支里，再在探测内部使用一次带 default 的 select。关键是把高频重试变成有上限的节奏。

不要在每一轮循环中调用 time.NewTicker 或 time.After 来“临时休眠”。周期对象应在循环外创建，并在函数结束时停止；一次性延时则应明确它的生命周期和退出路径。

大多数工作循环应该删除 default

如果目标只是“有任务就处理，没有任务就等”，最简单的修复是删除 default。下面的 select 会在任务通道没有数据时阻塞，任务到达后才继续执行，因此不会靠空转消耗 CPU：

for {
	select {
	case job := 

如果循环还要响应停止信号，就把停止通道一起放进同一个阻塞式 select。这比在循环外另设一个共享布尔值更容易保证退出时机。

func runWorker(ctx context.Context, jobs 

这里的 ctx.Done() 是取消信号通道。调用方取消上下文后，worker 可以从等待中返回；如果使用 context.WithCancel、WithTimeout 或 WithDeadline 派生上下文，调用方还应在不再需要时调用对应的 cancel 函数。

周期任务应该怎样组合

如果 worker 既要处理任务，又要定期刷新指标，还要响应取消，可以把三个等待点放到同一个 select 中：

func runScheduledWorker(ctx context.Context, jobs 

这个结构的重点不是 ticker 的具体间隔，而是循环始终有明确的等待对象。任务、周期和取消都没有发生时，goroutine 会停在 select 上，而不是反复执行空分支。

保留 default 时的两个边界

第一，default 可以用于“尝试发送但不阻塞调用方”的一次性动作，例如限量写入一个可能暂时没有接收者的 channel。但这种尝试通常应该在一个有限范围内完成，不能在外层无限重试。

func trySend(out chan

第二，如果业务确实需要轮询，至少要明确轮询间隔、退出条件和失败后的退避策略。不要用 runtime.Gosched 把忙等伪装成等待：它只能让出当前调度机会，不能提供稳定的时间间隔，也不能替代取消信号。

最小复查：确认循环是否还在空转

可以用一段小程序观察循环计数。下面的示例不依赖具体业务，只比较“default 立即重试”和“ticker 定时重试”的行为趋势：

func countLoops(ctx context.Context, interval time.Duration) uint64 {
	var loops atomic.Uint64
	ticker := time.NewTicker(interval)
	defer ticker.Stop() // 计数函数结束时停止 ticker

	for {
		select {
		case 

复查时关注的是循环是否有明确等待点、取消后是否能返回、ticker 是否只创建一次并在退出时停止。不要把某一台机器上的单次计数当成固定性能结论；调度器、负载和时间间隔都会影响观测结果。

怎么选写法

常见追问

有 default 就一定会忙等吗？

不一定。单次 select 或有限次数的非阻塞尝试不会形成持续空转；真正危险的是它位于没有等待、没有休眠、没有退出条件的高速循环中。

能不能在 default 里加 time.Sleep？

可以暂时降低循环频率，但固定睡眠通常不如 ticker 或阻塞式 select 清晰。若循环还要及时响应任务和取消信号，应把等待对象直接放入 select，而不是把所有事件都推迟到 sleep 结束后。

为什么不直接用一个布尔变量控制退出？

共享布尔变量既要考虑同步，又不能把阻塞中的 goroutine 唤醒。把 ctx.Done() 放进 select，可以让取消信号成为和任务一样明确的等待事件。