go 无法真正“预测”非阻塞 channel 发送是否成功，因为任何预检测都会引入竞态；正确做法是将消息生成与发送解耦（如用信号 channel 或 sync.cond），或接受 select default 的原子性保障。
在 Go 并发编程中，select 配合 default 是实现非阻塞发送的标准且唯一原子性保障的方式：
select {
case messages <- msg:
fmt.Println("sent message", msg)
default:
fmt.Println("send failed: channel full or receiver not ready")
}这段代码的语义是：“尝试发送，若不可立即完成则跳过”，其核心价值正在于 原子性——判断与发送是一体操作，不存在中间状态被并发修改的风险。
⚠️ 关键误区：试图“先检查再发送”（例如幻想存在 canSend() 方法）是危险且无效的。原因在于：
- Channel 的就绪状态（如缓冲区是否有空位、是否有 goroutine 在等待接收）瞬息万变；
- 即使你通过某种方式“探测”到当前可发送，下一纳秒它就可能因其他 goroutine 的操作而变为不可发送；
- 这种检测 + 发送的两步操作必然引入 race condition，破坏并发安全性。
✅ 正确解法一：延迟生成消息（推荐）
将耗时或依赖上下文的消息构造逻辑移入 select 的 case 分支内，确保仅在确定能发送时才生成：
select {
case <-readySignal: // 假设 readySignal 是一个通知“可发送”的 channel
msg := expensiveMessageGenerator() // 仅在此刻生成
messages <- msg
fmt.Println("sent message", msg)
default:
fmt.Println("skipped: no slot available")
}✅ 正确解法二：使用 sync.Cond 实现条件等待（适用于复杂同步场景）
当需结合锁与条件判断（如监控缓冲区水位、自定义就绪逻辑）时，sync.Cond 提供更精细的控制：
var mu sync.Mutex
cond := sync.NewCond(&mu)
// 发送方（带条件检查）
mu.Lock()
for len(messages) == cap(messages) { // 模拟：缓冲满则等待
cond.Wait() // 释放锁并休眠，直到被唤醒
}
msg := generateMsg()
messages <- msg
mu.Unlock()
// 接收方处理完后唤醒发送方
mu.Lock()
cond.Signal()
mu.Unlock()? 总结：
- Go channel 的设计哲学是 “通信胜于共享内存”，而非提供状态查询接口；
- select {... case ch 原子性的发送尝试，这是语言层面的安全契约；
- 若业务逻辑强制要求“预判”，请重构为信号驱动（如额外 channel 通知就绪）、状态封装（如包装 channel + mutex + 条件变量），而非绕过 select 机制；
- 永远警惕“检查-然后-执行”模式在并发环境中的固有缺陷——Go 的 select default 正是为了终结这种反模式而存在。
