Go select 没有 default 时为什么会阻塞

排查 Go 并发代码时，最容易误判的一种现象是：程序走到 select 后像“卡死”一样没有输出。只要没有 default，这通常是正常语义——当所有发送和接收 case 都暂时不能完成时，当前 goroutine 会等待，直到至少有一个通信操作就绪。真正要查的是：有没有生产者、channel 是否为 nil，以及业务是否本来就需要立即返回。

一个没有 default 的 select 为什么会停住

例如下面的消费者只有在 jobs 有值可读时才会继续：

package main

import "fmt"

func main() {
    jobs := make(chan string)

    select {
    case job := 

这里没有另一个 goroutine 向无缓冲的 jobs 发送数据，所以接收操作没有就绪。Go 规范规定，缺少 default 时，select 会阻塞到至少一个通信操作可以继续；它不会因为“暂时没有数据”自动执行下一行。

如果同时放入多个 case，规则仍然相同：只要有一个通信能完成就选一个；如果一个也没有，就等待。多个 case 同时就绪时，规范定义的是均匀伪随机选择，不应把 case 的书写顺序当作优先级。

没有 default 时，select 到底在等什么

先把“不能读”拆成几种情况，排障会快很多：

尤其要警惕这样的变量覆盖：

var updates chan string

select {
case value := 

如果它本来应该由构造函数返回，却因为某个错误分支保持 nil，那么现象就是永久等待。此时加入 default 只能把问题变成“每轮都没有更新”，并没有修复 channel 的生命周期。

default、超时和取消分别解决什么问题

三种写法对应三种业务意图，不要只为让程序“动起来”而随意添加：

// 立即检查一次，不等待；适合可选地取走现有消息。
select {
case value := 

上面的示例需要导入 time 和 context。生产代码中，如果等待逻辑会被频繁循环调用，通常优先复用 time.Timer 并在退出路径停止它；一次性的短等待使用 time.After 更容易读。无论选哪种方式，都要让成功、超时和取消在调用方看来是不同结果。

循环里如何避免忙等和永久挂起

最常见的复盘根因不是 select 本身，而是循环策略和退出条件没有配套。带 default 的循环如果没有工作时立刻下一轮，就会形成忙等，CPU 占用上升；不带 default 的循环如果生产者永远不发送，也会让 goroutine 长期留在等待集合中。

可以按这张小清单复查：

• 需要“有消息再做事”时，保留阻塞 select，并确认生产者最终会发送或关闭 channel。
• 需要“马上知道有没有”时，使用 default，同时给空结果设计退避、休眠或下一项工作。
• 需要“最多等多久”时，放入定时器分支；需要“调用方说停就停”时，监听 context.Done。
• channel 由哪个组件创建、关闭、置 nil，要写在接口约定里；接收方不要擅自关闭共享 channel。

一句话判断：没有 default 的 select 会阻塞，是因为当前没有可完成的通信；它是否是 bug，取决于这个等待有没有合法的生产者、关闭信号或取消边界。

相关问题

select 里只有 default 会怎样？ 每次都会立即进入 default，放进无限循环会变成忙等。

关闭后的 channel 会让 select 永久阻塞吗？ 不会。接收 case 会持续就绪，因此循环必须用第二个返回值判断结束并移除该 case。

nil channel 适合放进 select 吗？ 可以用来动态禁用某个 case，但必须明确何时替换成有效 channel，否则该分支会永久不可执行。

规范依据：https://go.dev/ref/spec#Select_statements；默认选择示例：https://go.dev/tour/concurrency/6。