default 分支会立即返回，不尝试任何 case；只要所有 case 无法立即执行，select 就零延迟进入 default，与 if-else 语义不同。
select default 分支会立即返回，不是“等一会儿再试”
很多人以为 default 是“尝试一下通道，不行就跳过”，实际它根本不会尝试——只要所有 case 无法**立即执行**，select 就直接进 default，零延迟、零阻塞。这和你写 if cond { ... } else { ... } 的语义完全不同，它不带任何等待或退让。
典型表现是：一个空的无缓冲 chan int，配上 select { case ，只要没人往 <code>ch 写，default 就每轮都触发。在 for 循环里，这就变成每秒几百万次的空转。
-
default不会让 goroutine 进入 waiting 状态，调度器会反复把它拉起来检查通道——本质是忙等待（busy loop） - 哪怕只加一行
fmt.Println，也会因系统调用短暂让出时间片，掩盖问题但不解决本质 - CPU 使用率飙升时，
pprof中常看到runtime.futex或runtime.mcall占比异常高，这是调度器被高频唤醒的信号
什么时候该保留 default，什么时候必须删掉
保留 default 只适用于明确需要「非阻塞探测」的场景，比如轮询多个队列看有没有新任务、做轻量级健康检查、或实现带退避的重试逻辑。除此之外，绝大多数通信循环都应该去掉 default。
- 想“等任一通道就绪” → 删掉
default，让select自然阻塞，这是 Go 并发模型的设计原意 - 想“最多等 100ms，超时就做别的事” → 用
case ，而不是 <code>default+time.Sleep - 真要轮询且不能阻塞 → 必须加退避，例如
default: time.Sleep(1 * time.Millisecond); continue，否则 CPU 必爆
带 default 的 select 在无限循环中极易掩盖真实问题
高频 default 打印或日志，会让真正该发生的通信事件（比如 关闭信号、<code>counter 数据发送）被淹没在输出风暴里。你看到的不是“程序卡住了”，而是“程序跑得太快，快到没时间干正事”。
- 主 goroutine 每毫秒执行数千次
default，而接收方可能 1 秒才处理一次，发送永远失败，逻辑彻底失序 - 调试时用
fmt打点反而更难定位问题——因为日志本身也消耗资源，还可能触发 GC 或锁竞争 - pprof 查
goroutine数量未必上涨，但 CPU 火焰图里全是selectgo和runtime.selectgo的扁平调用，这就是忙等待的特征
超时控制别用 default，用 time.After 更精准省资源
time.After 返回的是一个真正的 channel，它背后由 runtime timer 驱动，不依赖 goroutine 轮询。相比 default + time.Sleep，它既避免了调度开销，又不会因 sleep 时间不准导致逻辑偏差。
case 是单次触发，精确、低开销；<code>default+time.Sleep是每次循环都 sleep，误差累积且调度负担重- 如果超时后还需重试，用
time.NewTimer替代time.After，可复用并避免内存泄漏 - 注意：
time.After创建的 timer 不会自动 stop，短生命周期场景下影响小，但长运行服务中建议用timer.Reset复用
真正容易被忽略的不是语法对错，而是“默认分支让 select 变成同步轮询”这个事实——它看起来像并发原语，行为却接近裸循环。写完带 default 的 select，先问一句：我是在等信号，还是在自己当定时器？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
