唯一可靠的非阻塞写法是 select + default；len(ch) == cap(ch) 不可靠，因并发下 len 与 cap 读取非原子，且判断后状态可能立即改变。
Go 的 channel 默认就是阻塞的，不加控制地读写必然卡死 goroutine；唯一可靠、简洁、符合 Go 并发模型的非阻塞方案，就是 select + default。
为什么不能用 len(ch) == cap(ch) 判断 channel 是否可写
这个表达式只反映「此刻」的长度和容量，但并发环境下：写操作不是原子的，len 和 cap 读取之间可能已有其他 goroutine 写入或读出；即使刚判为“未满”，下一刻 ch 仍可能阻塞（比如缓冲刚好被填满）；更危险的是，若 channel 已关闭，<code>len(ch) 仍返回当前长度，但写入会直接 panic —— 而 select + default 能天然避开已关闭 channel 的写 panic。
非阻塞写入必须用 select + default，且 default 分支要明确语义
常见于任务分发、日志上报、结果回传等场景，当消费者处理慢或退出后，生产者不能被卡住：
select {
case resultChan <- data:
// 成功发出
default:
// 不是“兜底打日志”，而是控制流决策点：
// - 丢弃：log.Printf("dropping data: %v", data)
// - 降级：backupQueue.Push(data)
// - 返回错误：return fmt.Errorf("channel full")
// - 或直接 return（如健康检查 goroutine 中）
}- 别在
default里循环重试：for+select不加 delay 就是忙等，CPU 拉满却无进展 - 需要重试时，应引入 backoff（如
time.After(10 * time.Millisecond)）或换用带超时的select - 如果 channel 是接收方主动关闭的，
select会自然 fallback 到default，无需额外判断状态
非阻塞读取适用于轮询、信号监听、健康检查等“不想等”的场景
比如一个 goroutine 定期检查是否有新配置、中断信号或心跳包，但绝不能因 channel 空而挂起：
立即学习“go语言免费学习笔记（深入）”；
select {
case cfg := <-configChan:
applyConfig(cfg)
case sig := <-sigChan:
handleSignal(sig)
default:
// 真正的“空转安全”：不做任何事，立刻继续下一轮
// 不 sleep、不 log、不占资源——这才是非阻塞本意
}- 不要用
if len(ch) > 0替代：同样存在竞态，且无法处理关闭后的读（关闭后len可能 > 0，但再读就返回零值+ok=false） - 如果需要“最多等 100ms”，就把
default换成case - 注意：从已关闭的 channel 读会立即返回零值 +
ok=false，这和default行为不同，需按业务区分处理
真正难的不是写出 select + default，而是放弃“同步思维”——不再假设“我发了它就该收到”“我读了它就该有数据”。Go 的并发模型要求你把 channel 操作当作一次可能失败的通信尝试，而 default 不是补丁，是设计契约的一部分。
