17370845950

select语句必须至少有一个case，否则运行时panic死锁；空select{}非法，仅default合法非阻塞；多case就绪时随机选择，不保证顺序；函数调用在select前求值，可能引发阻塞。

select 语句必须至少有一个 case，否则会编译报错

Go 的 select 不是 switch 的变体，它专为通道操作设计，底层依赖于 goroutine 调度器的等待队列机制。如果写成空 select {}，程序会永久阻塞（deadlock），而写成只有 default 的 select 是合法的非阻塞轮询方式。

• 错误写法：

  select {} // 编译通过，但运行时 panic: all goroutines are asleep - deadlock!

• 正确轮询写法：

  select {
  default:
      // 非阻塞，立即返回
  }

• 必须有可通信的 channel case 才能参与调度；nil channel 的 case 永远不会就绪（可用于临时禁用某路）

多个 case 同时就绪时，select 随机选择一个执行

Go 运行时不保证 case 的执行顺序，哪怕 ch1 总是先发数据、ch2 后发，只要两者在 select 执行瞬间都已就绪，选哪个完全随机。这避免了调度偏向和饥饿问题，但也意味着不能靠书写顺序做逻辑依赖。

• 常见误判场景：监听超时与数据通道，以为 time.After 写在后面就“优先级低”，实际无意义
• 若需严格优先级（比如先响应取消，再处理数据），应拆成嵌套 select 或用 if select 组合判断
• 调试时可通过反复运行观察不同输出，验证是否真被随机调度

case 中调用函数会导致意外阻塞或副作用

每个 case 表达式在 select 开始前就被求值，包括函数调用。如果函数内部有阻塞操作（如 http.Get、time.Sleep），整个 select 就卡住了——不是某个 case 卡住，而是整个语句无法进入等待状态。

• 错误示例：

  select {
  case msg := <-ch:
      fmt.Println(msg)
  case <-time.After(expensiveFunc()): // expensiveFunc() 在 select 判定时就执行！
  }

• 正确做法：把耗时计算提到 select 外，或用变量缓存结果：

  timeout := expensiveFunc()
  select {
  case msg := <-ch:
      fmt.Println(msg)
  case <-time.After(timeout):
  }

• 尤其注意 make(chan int, 0) 和 make(chan int, 1) 对读写行为的影响，可能让本该阻塞的 case 突然就绪

default 分支让 select 变成非阻塞轮询，但频繁空转消耗 CPU

加入 default 后，select 不再等待任何通道，每次执行都立刻走 default 或某个就绪 case。这适合事件驱动型服务（如游戏 tick、状态检查），但若没配合适当休眠，会变成忙等待。

• 典型陷阱：在 for 循环里写 select { default: doWork() }，CPU 占用飙到 100%
• 缓解方式：default 中加 runtime.Gosched() 让出时间片，或搭配短时 time.Sleep(1ms)
• 更优解：用带缓冲的 channel 做信号聚合，减少轮询频次；或改用 timer.Reset() 复用定时器，避免反复创建 time.After

实际用得多的其实是「带超时的通道读取」和「多通道合并监听」这两种模式，前者要小心 time.After 创建开销，后者要注意所有 channel 关闭后如何退出循环——select 本身不感知关闭，得靠 value, ok := 显式判断。