必须用 select + default 实现非阻塞：channel 默认同步阻塞，select 无 default 会挂起 goroutine；加 default 后可立即 fallback，避免卡死。
Go channel 阻塞读写会卡死 goroutine，必须用 select + default 实现非阻塞
Go 的 channel 默认是同步的：往无缓冲 channel 写，没人读就卡住；从空 channel 读，没人写也卡住。这种阻塞不是错误，但会直接让 goroutine 挂起，线上服务里一两个没处理好的 channel 操作就能拖垮整个并发流程。
真正能破局的只有 select 语句配合 default 分支——它让 channel 操作变成“尝试性”的，不满足条件就立刻走默认逻辑，不等、不卡、不阻塞。
-
select本身不阻塞，但所有case都是阻塞式 channel 操作；没有default时，select就会一直等某个case就绪 - 加了
default，哪怕所有 channel 都不可读/不可写，也会立刻执行default分支，实现非阻塞语义 -
default不是“兜底日志”或“异常处理”，它是控制流的一部分，该返回、该跳过、该 fallback，都得在这里写清楚
非阻塞写入 channel：用 select + default 避免生产者卡死
常见于任务分发场景：worker goroutine 往结果 channel 发送数据，但消费者处理慢或已退出，channel 缓冲满后继续写就会永久阻塞。
正确做法是只在 channel 可写时才发，否则丢弃、重试或走降级路径：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
select {
case resultChan <- data:
// 成功写入
default:
// channel 满或已关闭，不阻塞，立刻处理
log.Printf("resultChan full, dropping data: %v", data)
// 或：return, continue, send to backup queue...
}- 不能用
len(ch) == cap(ch)判断是否满——这只能反映当前长度，无法保证下一刻能否写入（并发下状态瞬变） - 如果 channel 已关闭，写入会 panic，而
select+default能安全绕过，但更稳妥的是先用ok := ch 形式判断（仅适用于 select 外的单次尝试） - 别在
default里循环重试写入，那等于自己造了个忙等锁；需要重试应加延时或走 backoff 策略
非阻塞读取 channel：用 select + default 防止消费者空转或假死
比如定时检查 channel 是否有新消息，又不想被卡住——典型如健康检查 goroutine 或信号监听器。
错误写法是 if len(ch) > 0 { ，因为 <code>len() 和 之间存在竞态，可能读到 nil 或 panic。
正确且原子的方式是：
select {
case msg := <-signalChan:
handleSignal(msg)
default:
// 没消息，继续干别的，不等
doBackgroundWork()
}-
default分支必须存在，否则select会阻塞等待signalChan有数据 - 如果 channel 可能被关闭，
在关闭后会立即返回零值且 <code>ok == false，但这个行为仍需在case中显式接收，default不会自动捕获关闭状态 - 别把耗时操作塞进
case，尤其网络请求或磁盘 IO——它会让其他case长时间得不到调度，select不是并发调度器
select 里多个 channel 同时等待时，default 的优先级和随机性
当多个 case 同时就绪（比如两个 channel 都有数据可读），Go 运行时会**伪随机选择一个**执行，不是按代码顺序，也不是按 channel 状态“谁更急”。default 的作用是打破这种等待，但它本身没有优先级——它只在**所有 case 都不就绪时才触发**。
- 如果一个
case就绪了，哪怕default在第一行，也不会执行；default是“全都不行时的备选”，不是“优先选项” - 想实现“优先读 A，A 没数据再读 B”，得嵌套
select或用带超时的select（time.After），不能靠排列顺序 - 测试时容易误判行为，因为多 goroutine 下就绪时机高度不确定；别依赖某次运行结果推断逻辑，要用
runtime.Gosched()或明确同步点验证
真正难的不是写对 select，而是想清楚每个 case 和 default 对应的真实业务含义：哪条路是主干，哪条是降级，哪条该丢弃，哪条该报警。channel 阻塞问题，本质是并发协作契约没定义清楚。
