能，但仅当select中所有通道操作都不可立即完成时default才立刻执行；它不是跳过阻塞的开关，而是无可用通道操作时的兜底路径，若default内含阻塞操作（如time.Sleep），整段逻辑仍会卡住。
select 里 default 分支真能“非阻塞”吗？
能，但仅当 select 中所有通道操作都不可立即完成时，default 才会立刻执行。它不是“跳过阻塞”的开关，而是“无可用通道操作时的兜底路径”。很多人误以为加了 default 就等于函数调用不卡住，结果在 case 左侧通道有数据时，<code>default 根本不会运行——它从不抢跑，只捡漏。
为什么轮询场景下 default 常被误用？
典型错误是把轮询写成：不断 select + default，却没意识到这本质是忙等（busy-wait），CPU 占用飙升。更隐蔽的问题是，在多 goroutine 竞争同一通道时，default 可能反复触发，而真正该处理的消息却被其他 goroutine 拿走，导致逻辑丢失。
-
default不提供“尝试读取并返回是否成功”的语义，它只表示“此刻所有 case 都不可达” - 若想判断通道是否就绪，应配合
len(ch)（仅限带缓冲通道）或用select+default+ 短暂time.Sleep控制频率 - 对无缓冲通道，
len(ch)永远为 0，不能靠它判断是否有 goroutine 正在等待发送
如何写出真正低开销的通道轮询逻辑？
关键不是去掉阻塞，而是让轮询有节奏、可退让。下面这个模式比纯 default 更可靠：
for {
select {
case msg := <-ch:
handle(msg)
default:
// 短暂让出调度权，避免空转
runtime.Gosched()
// 或者 sleep 1ms 控制轮询密度
// time.Sleep(time.Millisecond)
}
}-
runtime.Gosched()让当前 goroutine 暂停，允许其他 goroutine 运行，比time.Sleep开销小，适合高频轮询 - 如果轮询是为了“等某个条件出现”，优先考虑用
sync.Cond或context.WithTimeout，而非死循环 +default - 多个通道参与轮询时，
default触发不代表所有通道都空，只代表当前这一轮select没匹配到任何可执行 case
容易被忽略的边界：nil 通道和已关闭通道
select 对 nil 通道和已关闭通道的行为完全不同，直接影响 default 是否触发：
立即学习“go语言免费学习笔记（深入）”；
- 如果某个
case是，该 case 永远阻塞，<code>default仍可能执行（只要其他 case 也不就绪） - 如果某个
case是从已关闭通道接收：会立即返回零值，<code>default不会执行 - 向已关闭通道发送会 panic，但
select中的ch case 若对应通道已关闭，该 case 会被视为“不可执行”，从而可能触发 <code>default
实际写轮询时，别依赖 default 推断通道状态，该显式检查就显式检查。
