是的，select 有 default 时仅在所有 case 都不可立即执行时才触发 default，否则仍会阻塞。
select 有 default 就一定不阻塞？
是的，但仅限于“所有 case 都不可立即执行”时才触发 default；只要任一 或 <code>ch 能零延迟完成，<code>default 就完全不会运行——它不参与竞争，也不是“低优先级分支”。
常见误判场景：
- 对无缓冲 channel 执行
，但另一端没 goroutine 在等发送 → 不就绪 → 走 <code>default - 向已满的带缓冲 channel 发送
ch → 不就绪 → 走 <code>default - channel 已关闭，
立即返回零值 → 就绪 → 不走 <code>default
关键点：就绪与否只看“此刻能否完成”，不预测、不等待、不调度。
default 不能当超时用，为什么？
因为 default 是即时判断，而 time.After 是延时信号；两者逻辑冲突——default 在 select 开始时就检查所有 case 是否阻塞，一旦全阻塞立刻执行，根本不会等到 time.After 的时间点。
立即学习“go语言免费学习笔记（深入）”；
错误写法（永远打不出“等太久了”）：
select {
case x := <-ch:
handle(x)
default:
fmt.Println("等太久了") // ❌ 这里立刻执行，和时间无关
}正确做法是用 time.After 替代 default：
select {
case x := <-ch:
handle(x)
case <-time.After(100 * time.Millisecond):
fmt.Println("等太久了") // ✅ 到点才触发
}想让某个 channel 优先处理，能靠写在前面吗？
不能。Go 的 select 对就绪的多个 case 是伪随机选择，书写顺序毫无影响。
真正可控的做法是把高优通道的探测提前到 select 外部：
- 先用非阻塞接收试探：
if val, ok := - 只在
chA空或已关时，才进 select 协调chB和超时 - 避免把
chA和chB放进同一个 select，否则两者都就绪时结果不可控
本质是用“显式判断 + 分层 select”替代“依赖顺序”，才能获得确定性。
只有一个 case 加 default，还算 select 吗？
算，但它行为已彻底改变：从“等消息”变成“查一次状态”。
比如向可能满的 channel 发送：
select {
case ch <- data:
// 成功发送
default:
// ch 满了，或没人收，立刻走这里
}这种模式常用于背压控制、快速失败、状态轮询等场景；但它不是“兜底逻辑”，而是明确告诉 runtime：“别等，现在不行就跳过”。
容易被忽略的是：加了 default 后，整个 select 就不再具备同步协调能力，它只是一个瞬时快照工具——你得自己保证外部逻辑能应对“什么都没发生”的情况。
