select 中加 default 使整个 select 立即返回，实现非阻塞调度；它仅在无 channel 就绪时执行，并非通用非阻塞开关，也不能可靠探测 channel 是否有数据。
select 里加 default 就是非阻塞收发？
对，但只在 select 语句中成立——它让整个 select 立刻返回，不等任何 channel 准备就绪。这不是“非阻塞 channel 操作”的通用开关，而是 select 自身的调度行为：没 case 能立即执行，就走 default。
常见错误是以为加了 default 就能安全地“试探” channel 是否有数据，结果发现 default 总被选中，或者漏掉了真正的数据。
-
default不代表“channel 空”，只代表此刻无 goroutine 在该 channel 上等待（或缓冲未满/未空） - 如果其他 case 的 channel 正好可读/可写，
default永远不会执行——哪怕你只是想“看看有没有” - 多个可执行 case 时，
select是随机选一个，default只在全部不可执行时兜底
用 default 实现“尝试读取，不等”
这是最典型也最容易出错的场景：你想从 ch 读一个值，但不想卡住。必须搭配 select + default，不能单独对 channel 做 <-ch。
注意：读操作必须用 val, ok := <-ch 形式，否则即使走到 default，你也无法区分是“没数据”还是“channel 已关闭”。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 如果
ch是无缓冲 channel，且当前无人发送，<-chcase 阻塞 → 走default - 如果
ch有缓冲且非空，<-ch立即成功 → 不走default - 如果
ch已关闭，<-ch立即返回零值 +ok == false→ 也不走default
select {
case val, ok := <-ch:
if ok {
fmt.Println("got", val)
} else {
fmt.Println("channel closed")
}
default:
fmt.Println("no data available right now")
}
default 和 timeout 混用时的优先级陷阱
很多人想“最多等 100ms，没数据就放弃”，于是写 select + time.After + default。但这样会出问题：default 总是优先于 time.After 执行，导致永远等不到超时。
根本原因：time.After 返回的是一个 channel，它在 100ms 后才可读；而 default 在每次 select 开始时都“立刻可执行”。只要没其他 case 就绪，default 就赢了。
- 正确做法：去掉
default，只留time.After和业务 channel - 如果真需要“立即检查 + 超时兜底”，得拆成两步：先用
select+default尝试一次；失败后再用不含default的select等超时 - 别在同一个
select里同时放default和time.After——它们语义冲突
default 分支没有变量作用域，容易意外覆盖
default 看似独立，但它和所有 case 共享同一层作用域。如果你在某个 case 里声明了变量，又在 default 里用了同名变量，Go 编译器不会报错，但行为可能不是你想要的。
更隐蔽的问题是：你在 case 中给某个外部变量赋值，结果因为走到了 default，那个赋值根本没发生，后续逻辑却默认它已设置。
- 避免在
case或default中复用同名变量，尤其不要依赖“某 case 必定执行” - 初始化关键变量一定要在
select外完成，或在每个分支里显式赋初值 - 调试时注意：
default执行路径可能比你以为的更频繁，尤其在高并发或 channel 负载不均时
真正难的不是写对 default，而是想清楚你到底要“跳过等待”，还是“确认空状态”，或是“做兜底动作”——这三个意图对应完全不同的结构，混在一起就会反复掉坑。
