default分支使select非阻塞：当所有case均不可立即执行时立即执行default，而非等待；它不参与case竞争，也不提供超时能力，仅反映当前无就绪channel。
select 里 default 分支让通信变成非阻塞
Go 的 select 默认是阻塞的：如果没有就绪的 case，它会一直等下去。加了 default 就完全不同——只要所有 channel 操作都不可立即完成，select 立刻执行 default 分支，不挂起 goroutine。
这是实现“尝试发送/接收但不等待”的唯一标准方式。比如你想往一个可能满的 channel 发数据，又不想卡住当前逻辑：
select {
case ch <- data:
// 成功发送
default:
// ch 已满或无人接收，立刻走这里
}注意：default 不代表“兜底逻辑”，它只在**所有 channel 操作都非就绪时触发**；一旦某个 case 就绪（哪怕多个），select 仍按随机公平调度选一个执行，default 完全不参与竞争。
为什么不能用 default 做超时兜底？
default 本身不带时间语义，它只反映“此刻无就绪 channel”。想实现“最多等 100ms”，必须搭配 time.After 或 time.NewTimer：
立即学习“go语言免费学习笔记（深入）”；
- 错误写法（以为能超时）：
select { case x := <-ch: handle(x) default: fmt.Println("没拿到？") // 这里立刻执行，和时间无关 } - 正确写法（真超时）：
select { case x := <-ch: handle(x) case <-time.After(100 * time.Millisecond): fmt.Println("等太久了") }
time.After 返回的是一个 ，它会在指定时间后自动可读，从而让 <code>select 在超时后跳出。别用 default 替代这个逻辑——它们解决的是两类问题。
default 分支常见误用场景
很多人把 default 当成“轮询空转”的手段，结果写出高 CPU 占用的 busy-wait：
- 错误模式（空转耗资源）：
for { select { case x := <-ch: process(x) default: // 没数据就立刻再查，没有停顿 } } - 修复建议：
– 加runtime.Gosched()让出时间片
– 改用time.Sleep(1 * time.Microsecond)降频
– 更好做法是直接去掉default，改用带超时的select，或依赖 channel 关闭信号
还有一种典型误用：在需要严格顺序处理的场景里滥用 default，导致消息被静默丢弃。比如日志上报 channel 满了，你用 default 忽略，而不是缓存、降级或告警——这会让可观测性彻底失效。
非阻塞通信的实际边界在哪？
加了 default 并不等于“完全不阻塞”。它只消除了 select 自身的阻塞，但无法规避以下情况：
-
case中的函数调用本身可能阻塞（比如http.Get） - 如果
default分支里有死循环或长耗时操作，整个 goroutine 依然卡住 - 对带缓冲 channel 的非阻塞发送，仅当缓冲区未满才成功；若满，仍走
default—— 但这不代表 channel 逻辑错了，只是你要自己处理背压
真正关键的判断点在于：你是否清楚每个 case 的就绪条件，以及 default 触发时业务上该做什么。很多并发 bug 不是语法写错，而是对“何时该丢、何时该等、何时该重试”缺乏明确策略。
