select + default 不是轮询而是非阻塞探测，因为它仅判断当前能否零延迟完成通信（如空无缓冲通道立即读失败），而非周期性检查状态；若所有case不可立即执行则立刻执行default，不等待、不轮询。
select + default 为什么不是轮询，而是非阻塞探测
很多人误把 select 加 default 当成“轮询”，其实它根本不会检查通道状态——它只看当前能否零延迟完成通信操作。比如对一个空的无缓冲 ch 执行 ，若没有 goroutine 在另一端等待接收，这个操作就不可就绪，<code>select 立刻跳进 default；但如果是已关闭的 ch， 就是就绪的（立即返回零值），哪怕通道里没数据。
关键点在于：default 不是“检查后 fallback”，而是“所有 case 都无法立即执行时的唯一出口”。它不消耗 CPU 去扫描，也不触发调度器轮询，只是运行时的一次快速判断。
- 对未关闭、无协程协作的无缓冲 channel，
永远不就绪 → 必走 <code>default - 对已关闭的 channel，
总是就绪 → <code>default不会被执行 - 对缓冲 channel，
是否就绪取决于当前是否有数据 → 有则执行 case，无则走 <code>default
频繁 default 导致 CPU 空转？别乱加 sleep
在循环里写 select { default: ... } 确实可能跑满一个 CPU 核——但这不是 default 的错，而是你没控制节奏。直接在 default 里加 time.Sleep(1 * time.Millisecond) 是常见但粗糙的做法，尤其在高精度响应场景下会引入不可控延迟。
更合理的做法是结合业务节拍：
- 需要毫秒级响应（如实时信号采集）→ 用
time.After或time.Tick控制最小间隔，避免纯忙等 - 仅需定期探查（如健康检查）→ 把
select放进time.Tick(d).C的循环中，让 ticker 主导节奏 - 退出信号优先级高 → 用
select { case ，不 sleep，靠外部信号驱动退出
非阻塞发送和接收的正确写法
非阻塞操作的核心不是“有没有数据”，而是“这次通信能不能立刻完成”。所以不能只看 channel 类型，得看当前上下文是否满足通信条件。
接收非阻塞：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
select {
case msg := <p>发送非阻塞（尤其对缓冲 channel）：</p><pre class="brush:php;toolbar:false;">select {
case ch
- 向已关闭的 channel 发送会 panic，所以发送前最好先确认 channel 是否还活着（例如用
select配合done通道判断生命周期） - 接收时用
v, ok := 能同时判断是否关闭，但放在 <code>default分支外才有意义；default里无法获知关闭状态 - 不要在
case中调用可能阻塞的函数（如http.Get），它们会在select进入前就执行，导致整个select卡住
nil channel 在 select 中的隐藏用途
把某个 case 的 channel 设为 nil，等于临时禁用那一路——因为对 nil channel 的任何操作永远不就绪。这比用布尔开关 + if 判断更符合 Go 并发模型的设计哲学。
典型场景：动态启用/禁用某类事件监听：
var logCh chan string
if enableLogging {
logCh = make(chan string, 10)
go func() { /* producer */ }()
}
// 后续 select 中：
select {
case msg :=
- 当
logCh == nil时，case msg := 永远不参与调度，相当于“静音”该路 - 无需额外条件判断，
select自动忽略nilcase，代码更干净 - 注意：不能对
nilchannel 执行发送，否则 panic；但接收是安全的（永远阻塞，但被select屏蔽）
真正容易被忽略的是：select 的“就绪”判断发生在 goroutine 调度器层面，不是用户代码可干预的时机。写 default 不是为了轮询，而是为了在通信不可行时拿到控制权——这个边界，决定了你是用 Go 写并发，还是在用 Go 模拟轮询。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
