加default使select非阻塞，因其在所有case不就绪时立即执行default分支；无default则阻塞等待。非阻塞读需用val, ok := <-ch判断关闭状态，单用val会混淆零值与关闭。
Go里用select做非阻塞channel读写，为什么加default就变非阻塞？
因为select默认是阻塞的：没有就绪的case时会一直等。加上default后，只要所有channel都不可读/不可写，立刻执行default分支，跳过等待——这才是“非阻塞”的实质。
常见错误是以为不写default、只写一个case就是非阻塞，其实它照样卡住。也有人误把timeout（用time.After）当非阻塞，那是超时控制，不是无等待。
-
default必须显式写，不能省略；哪怕只有一条case，没default就是阻塞 - 多个
case同时就绪时，select随机选一个执行，default只有在全部不就绪时才触发 - 如果想“尝试读但不想等”，必须配
default；只靠select本身不解决阻塞问题
单个case + default能安全读chan int吗？
能，但要注意零值和关闭状态。从已关闭的channel读会立即返回零值（0），不会panic；但你无法单凭返回值区分“刚关闭”和“真写了0”。所以非阻塞读常配合ok标识判断：
val, ok := <-ch
if !ok {
// ch已关闭
} else {
// 读到了有效值
}如果只用val := <-ch忽略ok，关掉的channel会让你误以为有数据。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 未关闭的channel上非阻塞读不到数据时走
default，不会返回零值 - 已关闭的channel上非阻塞读一定成功，返回零值+
ok=false - 别在
default里假设“没读到=channel空”，可能只是暂时没人发，也可能已关闭
select里混用带缓冲和无缓冲channel，default还可靠吗？
可靠，但行为差异容易被忽略。无缓冲channel要求收发双方同时就绪；带缓冲的只要缓冲区有空位（写）或有数据（读）就算就绪。所以同样一个select，对带缓冲channel更容易进case，而不是掉进default。
比如向满的带缓冲channel写，即使加了default也会阻塞——不对，等等：这是错觉。实际上，写满的带缓冲channel在select中仍是“不可写”状态，所以会走default。真正阻塞只发生在单独的ch <- x语句中。
-
select中所有channel操作都是原子检查，不实际执行；所以满buffer写、空buffer读都会判为“不可行”，从而触发default - 但如果你在
case里做了额外逻辑（比如先len(ch)再写），那和select无关，纯属自己引入竞态 - 缓冲大小影响的是“就绪概率”，不影响
default的语义正确性
为什么生产代码里很少见裸select { default: }？
因为纯default等于空转，CPU空耗。真实场景需要配合退出信号、重试间隔或状态检查。比如轮询多个channel时，光写default会让goroutine疯狂循环，而加time.Sleep又可能错过即时消息。
更合理的做法是用time.After做轻量等待，或者用context.WithTimeout统一控制生命周期。但注意：time.After在select里每次都会新建timer，短周期轮询要小心泄漏。
- 裸
default适合极短时探测（如中断信号检查），不适合持续轮询 - 高频非阻塞读建议用带buffer channel + 固定size的批量处理，减少
select调用次数 - 一旦涉及超时、取消、重试，优先用
context而非手搓time.After，避免timer堆积
非阻塞的核心从来不是“快”，而是“不卡住主流程”。什么时候该等、等多久、等不到怎么办——这些决策比select语法本身重要得多。
