Go通道默认阻塞，无内置非阻塞函数；必须用select+default实现非阻塞发送/接收，因任何预检与发送分离的操作都会引发竞态，且语言不提供canSend等原子查询接口。
非阻塞发送和接收通道操作，必须用 select + default 实现，没有单独的“非阻塞函数”——Go 语言里根本不存在 chan.SendNonBlocking() 或类似方法。
为什么不能直接调用 send/receive 做非阻塞操作
Go 的通道操作默认是同步且阻塞的：ch 会一直等接收方就绪，<code>v := 会一直等发送方就绪。强行绕过阻塞只能靠 <code>select 的多路复用机制，而 default 分支正是用来兜底“不等待”的逻辑。
- 试图对 nil channel 执行 send/receive 会永久阻塞（不是 panic）
- 对已关闭 channel 接收会立即返回零值，但发送会 panic：
send on closed channel -
select中多个 case 同时就绪时，运行时随机选一个，不能指定优先级
用 select + default 实现非阻塞 send 和 receive
这是唯一可靠方式。关键点在于：把通道操作放在 select 的 case 中，加上 default 分支表示“没准备好就跳过”。
// 非阻塞发送
select {
case ch <- v:
// 成功发送
default:
// 通道满或无接收者，发送失败，不阻塞
}
<p>// 非阻塞接收
select {
case v := <-ch:
// 成功接收
default:
// 通道空或无发送者，接收失败，不阻塞
}- 如果通道是带缓冲的，
ch 在缓冲未满时会立即成功；否则进入 <code>default - 如果通道是无缓冲的，
ch 只有在另一端恰好执行 <code> 时才成功，否则走 <code>default - 对已关闭的 channel，
在 <code>select中仍会立即触发（返回零值），不会进default
常见误用：用 timeout 伪装非阻塞
有人用 time.After 或 time.NewTimer 配合 select 实现“超时放弃”，但这本质是限时阻塞，不是非阻塞。它仍会等待最多 N 毫秒，而真正的非阻塞要求 0 延迟。
立即学习“go语言免费学习笔记（深入）”；
// ❌ 这不是非阻塞，是“最多等 1ms”
select {
case ch <- v:
// ...
case <-time.After(1 * time.Millisecond):
// 超时
}
<p>// ✅ 这才是非阻塞
select {
case ch <- v:
// ...
default:
// 立即执行
}- 用
time.After会分配 timer 对象，频繁调用可能触发 GC 压力 - 超时路径和失败路径语义不同：一个是“等了但没等到”，一个是“根本不等”
- 若业务逻辑真正需要“尝试一次，不行就走”，必须用
default，而非 timeout
实际场景中容易忽略的细节
非阻塞操作常用于状态轮询、资源抢占、优雅退出等场景，但要注意几个隐性成本：
- 空
default分支会让 goroutine 忙循环，尤其在 tight loop 中——务必加runtime.Gosched()或短 sleep 控制节奏 - 对同一 channel 频繁做非阻塞 send，若下游消费慢，缓冲区持续积压，最终 OOM
- 无法通过返回值区分“通道满”和“通道已关闭”——两者都走
default，需额外维护 channel 状态标志 - 在 select 中混用多个 channel 时，非阻塞分支（
default）可能掩盖其他 channel 的就绪信号，逻辑易错
非阻塞通道操作看着简单，但它的“不等”背后藏着调度、内存、语义三层约束，稍不注意就会从优化变成负优化。
