go 无法真正“预测”channel 是否可发送，因为任何预检查都会引发竞态；正确做法是用 select + default 非阻塞发送，或借助信号 channel/sync.cond 实现条件化发送逻辑。
在 Go 并发编程中，常有人希望“先判断 channel 是否能立即发送”，再决定是否生成昂贵的消息（如序列化结构体、拼接字符串、调用外部 API 等）。但需明确一个核心原则：Go channel 的状态是瞬时的，任何脱离原子操作的“探测”都不可靠。
例如，以下伪代码看似合理，实则存在严重竞态：
// ❌ 错误示范：竞态不可避免
if isChannelReady(messages) { // 假设存在此函数
msg := generateExpensiveMessage() // 耗时操作
messages <- msg // 此时 channel 可能已满/关闭，导致阻塞或 panic
}isChannelReady 返回 true 的瞬间，另一 goroutine 可能已向 messages 发送一条数据，使其变满；或者 channel 已被关闭——此时再发送将 panic。因此，Go 标准库不提供、也不支持此类“预检”API。
✅ 正确解法始终围绕 原子性 和 协作式同步 展开：
方案一：使用信号 channel（推荐，简洁清晰）
引入一个只读的 ready channel（通常为 chan struct{}），由接收方或缓冲管理器控制其可读性：
// 发送方
select {
case <-ready: // 确认接收端已就绪（如已调用 receiveOne()）
msg := generateExpensiveMessage() // 此时才生成消息
messages <- msg
fmt.Println("sent message", msg)
default:
fmt.Println("receiver not ready — skipped")
}配套的接收端可主动通知就绪：
// 接收方（示例）
func receiver(messages <-chan string, ready chan<- struct{}) {
for range messages {
// 处理消息...
if cap(messages) > 0 { // 若为带缓冲 channel，可择机通知
select {
case ready <- struct{}{}:
default: // 避免阻塞，不强求通知
}
}
}
}方案二：使用 sync.Cond（适用于复杂状态协调）
当需基于共享变量（如缓冲区剩余容量、自定义队列状态）决策时，sync.Cond 提供更细粒度的条件等待：
var mu sync.Mutex
var cond *sync.Cond
var buffer []string
const maxCap = 10
func init() {
cond = sync.NewCond(&mu)
}
// 发送前检查（非阻塞）
func canSend() bool {
mu.Lock()
defer mu.Unlock()
return len(buffer) < maxCap
}
// 安全发送（原子检查+写入）
func trySend(msg string) bool {
mu.Lock()
defer mu.Unlock()
if len(buffer) >= maxCap {
return false
}
buffer = append(buffer, msg)
cond.Broadcast() // 通知等待者
return true
}⚠️ 注意：canSend() 仅用于调试或日志，不能替代 trySend()。因为两次调用间状态可能改变。
总结与最佳实践
- 永远避免“检查后执行”模式：if ch <- x 在 Go 中语法不合法，而 if isReady() { ch <- x } 是典型竞态陷阱。
- 坚持 select + default 原子语义：这是 Go channel 非阻塞操作的唯一正确范式。
- 消息生成延迟到 case 分支内：确保昂贵计算仅在确定能发送时触发。
- 优先选用 channel 信号而非锁：channel 是 Go 的第一公民，天然支持 goroutine 协作；sync.Cond 应作为补充，用于无法用 channel 表达的状态逻辑。
最终，Go 的设计哲学是：“用通信来共享内存，而不是用共享内存来通信”。预判发送失败不是缺失的功能，而是刻意为之的约束——它迫使开发者写出更健壮、更符合 CSP 模型的并发代码。
