default分支使select立即返回，避免Goroutine因所有channel不可读写而永久阻塞；它将“等待就绪”转为“立刻检查+决策”，确保Goroutine保持活跃以执行重试、熔断等响应逻辑。

default 分支让 select 立即返回，避免 Goroutine 无限挂起

在高并发场景中，大量 Goroutine 可能同时监听同一组 channel（比如连接池的 send 通道、广播通道、任务队列）。若 select 没有 default，而所有 channel 都不可读/不可写（例如接收端已退出、缓冲区满、发送方未就绪），该 Goroutine 就会永久阻塞——不是卡住一秒两秒，是彻底卡死，无法被调度器唤醒，最终拖垮整个服务。

default 的核心价值就在这里：它把“等待就绪”变成“立刻检查 + 立刻决策”。哪怕只是空分支 default: {}，也强制 select 不阻塞，Goroutine 能继续跑下一轮逻辑或执行清理动作。

• 无 default → select 阻塞，Goroutine 进入 waiting 状态，占用调度器资源
• 有 default → select 总是毫秒级返回，Goroutine 保持 active，可做重试、熔断、关闭连接等响应
• 典型误用：只加 default 却不处理状态，比如漏掉 val, ok := 中的 ok 判断，导致 channel 关闭后仍误判为“无数据”

default 不是探测工具，而是控制流开关

很多人想用 default 来“试探 channel 是否有数据”，这在高并发下尤其危险。因为 default 的触发条件不是“channel 为空”，而是“此刻无 goroutine 在另一端等待通信”——这个状态转瞬即逝，且受调度器影响极大。

比如一个带缓冲的 chan int 容量为 10，当前有 9 个元素，但此时没有 goroutine 正在 ，那 select { case 就会走 default；下一纳秒另一个 goroutine 开始读，它就又能成功了。这种非确定性在压测时极易暴露为随机丢消息或假性超时。

• 正确姿势：把 default 当作“快速失败出口”，不是“数据探针”
• 需要可靠判断 channel 状态？用 len(ch) 查当前长度（仅对带缓冲 channel 有效），或配合 close 信号 + ok 标志
• 高并发下更推荐组合策略：先 select+default 快速尝试，失败后进退避队列或降级逻辑，而非反复轮询

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

这是高并发中最隐蔽的坑之一。当业务要求“最多等 100ms，没数据就放弃”，有人会写：select { case v := 。结果发现永远走 default，超时逻辑形同虚设。

原因很直接：time.After(...) 返回的是一个 channel，它在 100ms 后才可读；而 default 在每次 select 开始时都“立即可执行”。只要 ch 没就绪，default 就赢了——根本等不到超时 channel 就绪。

• 正确做法一：去掉 default，只留 ch 和 time.After 两个 case
• 正确做法二：拆成两步——先用 select+default 尝试零延迟读；失败后，再用不含 default 的 select 等超时
• 注意：time.After 在高并发下会创建大量 timer，建议用 time.NewTimer 复用并显式 Stop

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

虽然看起来 default 是独立分支，但它和所有 case 共享同一层变量作用域。这点在高并发循环中特别容易翻车：比如你在某个 case 里声明了 err，又在 default 里复用同一个 err，结果前一次循环的错误值污染了本次逻辑。

更麻烦的是，如果多个 case 都赋值给同名变量（如 data），而你又没在 default 里初始化它，后续代码读到的可能是上一轮残留的脏值——这种 bug 在低 QPS 下很难复现，一到压测就爆发。

• 安全写法：所有变量都在 select 外声明，或每个 case 内用短变量声明（data := ）并确保 default 也显式赋初值
• 别依赖编译器报错：Go 不会警告 default 分支里未初始化的变量，只要它在作用域内声明过
• 高并发下建议加静态检查：用 go vet 或 staticcheck 扫描未初始化变量使用

真正难的不是写对一个 select，而是在上千个并发 Goroutine 里，让每个 default 都做对事：不阻塞、不误判、不污染、不抢跑。它不显眼，但一旦出问题，就是雪崩起点。