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