go 的 select 语句中若包含 default 分支，将变为非阻塞操作，持续轮询执行 default 分支，极易引发 cpu 占用过高和逻辑失控，需谨慎设计通信逻辑。

go 的 select 语句中若包含 default 分支，将变为非阻塞操作，持续轮询执行 default 分支，极易引发 cpu 占用过高和逻辑失控，需谨慎设计通信逻辑。

在 Go 并发编程中，select 是实现多路通道通信的核心机制。但当 select 包含 default 分支时，其行为会发生根本性变化：它不再阻塞等待通道就绪，而是立即执行 default 分支（如果其他 case 均不可立即进行）。这看似灵活，实则暗藏陷阱——尤其在无限循环中滥用 default，会导致典型的「忙等待（busy loop）」。

以下代码是典型反例：

for {
    select {
    case <-quit:
        fmt.Println("Bye!")
        return
    case counter <- i:
        fmt.Println("Send! " + strconv.Itoa(i))
    default:
        fmt.Println("Default! " + strconv.Itoa(i)) // ⚠️ 持续高频打印！
    }
}

由于 counter 是无缓冲通道，每次 counter <- i 都需有协程同时执行 <-counter 才能成功；而主 goroutine 仅在启动后顺序接收 6 次，远慢于发送协程的循环速度。因此，绝大多数 select 迭代中，case counter <- i 和 case <-quit 均不可达，default 分支被反复、即时触发——每秒可达数千万次，不仅输出刷屏，更会耗尽 CPU 资源，严重拖慢甚至掩盖真正需要处理的通信事件。

✅ 正确做法取决于具体场景：

• 若需“尝试发送/接收，失败即跳过”：保留 default，但务必加入退避（如 time.Sleep）或限频机制，避免空转：

  default:
      time.Sleep(1 * time.Millisecond) // 短暂让出时间片
      continue

• 若逻辑本意是“等待任一通道就绪”：直接移除 default，让 select 自然阻塞，这是最符合 Go 信道哲学的方式：

  select {
  case <-quit:
      fmt.Println("Bye!")
      return
  case counter <- i:
      fmt.Println("Send! " + strconv.Itoa(i))
  // no default → blocks until either channel is ready
  }

• 若需超时控制：使用 time.After 或 time.Timer 替代 default，实现优雅等待：

  case <-time.After(100 * time.Millisecond):
      fmt.Println("Timeout, doing fallback...")

⚠️ 注意事项：

• default 不代表“兜底逻辑”，而是“非阻塞兜底”——它牺牲了并发调度的公平性与资源效率；
• 在生产环境的高并发服务中，无节制的 default 是性能隐患，应通过压测识别；
• select 的随机公平性（多个可执行 case 时的伪随机选择）仅在阻塞模式下有意义；default 存在时，该特性常被绕过。

总结：select + default 不是万能开关，而是精确工具。优先让 Goroutine 阻塞等待真实事件，仅在明确需要零延迟响应或主动轮询时才引入 default，并辅以节流措施。真正的 Go 式并发，始于对阻塞的坦然接纳，而非对忙等待的妥协。