default分支使select立即返回，避免goroutine因channel阻塞而卡死；高并发下，向满缓冲通道或无人接收的无缓冲通道发送数据会导致goroutine永久阻塞，拖垮服务。

default 分支让 select 立即返回，避免 goroutine 卡死

高并发场景下，goroutine 一旦在 channel 操作上阻塞，就可能拖垮整个服务。比如向一个已满的缓冲通道或无人接收的无缓冲通道执行 ch ，当前 goroutine 会永久挂起——而 default 分支能强制 select 不等、不卡、立刻往下走。

• 它不是“兜底逻辑”，而是“此刻无就绪 channel 时的唯一出口”
• 多个 case 同时就绪？select 随机选一个执行，default 完全不参与竞争
• 哪怕只有一条 channel 刚好可写（例如接收端刚唤醒），default 就不会触发

为什么 websocket 广播必须用 select + default？

在 Gorilla WebSocket 的 hub.run() 中，广播循环要遍历所有客户端的 c.send 通道。若某个客户端网络卡顿、连接断开但未及时清理，其 c.send 通道就无法接收——不用 default，整个广播就会卡在这一个 client 上，其他用户全部掉线。

• 典型写法：select { case c.send
• default 这里不是“失败重试”，而是主动识别异常连接并清理资源
• 省略 default 或仅用缓冲通道替代，都无法保证广播逻辑的确定性响应

default 和 time.After 不能共存于同一个 select

想实现“立即尝试 + 超时兜底”，很多人误写成：select { case 。结果是 default 永远先赢——因为它在每次 select 开始时就“立刻可执行”，而 time.After 要等 100ms 才就绪。

• 正确做法：先用 select + default 尝试一次；失败后，再用不含 default 的 select 等超时
• default 没有时间语义，它只回答“此刻有没有就绪 channel”，不回答“等了多久”
• 混用会导致超时逻辑失效，且难以调试

default 分支共享变量作用域，容易意外覆盖

default 看似独立，但它和所有 case 共享同一层作用域。如果某个 case 声明了 val，而 default 里又用了同名变量，编译器不会报错，但行为可能不符合预期。

• 读取 channel 时推荐统一用 val, ok := 形式，避免在 default 里误判关闭状态
• 不要在 case 和 default 中重复声明同名变量，尤其涉及指针或结构体字段时
• 复杂逻辑建议把 default 内容抽成函数调用，明确隔离作用域

实际高并发系统里，default 的价值不在“多一个分支”，而在于它把“不可控的等待”变成了“可控的决策点”。最容易被忽略的是：它不探测 channel 状态，只反映调度时刻的就绪事实——这一秒没就绪，不等于下一秒还没数据，也不等于 channel 已关闭。