Go中channel阻塞需主动避免：无缓冲channel要求send/recv成对发生，否则永久阻塞；常用select+default实现非阻塞操作，但需防CPU空转；缓冲区仅缓解而非解决背压，应依吞吐节奏合理设置；超时与context控制必不可少，以防goroutine泄漏。

channel 阻塞时程序会卡住，必须主动避免

Go 中 chan 默认是无缓冲的，send 和 recv 必须成对发生，否则任一端都会永久阻塞。这不是 bug，是设计前提——但实际写业务时，你几乎总需要打破这种强同步约束。

用 select + default 实现非阻塞收发

这是最常用、最轻量的解法。不依赖缓冲区大小，也不改变 channel 语义，只是加一层“尝试”逻辑。

ch := make(chan int)
select {
case ch <- 42:
    // 发送成功
default:
    // 缓冲满或无人接收，立即返回，不阻塞
}
select {
case x := <-ch:
// 接收成功
default:
// 无数据可读，立即返回
}

• default 分支必须存在，否则 select 会一直等待
• 不能在循环里反复 select + default 轮询，容易吃光 CPU；需配合 time.Sleep 或事件驱动
• 适用于“尽力而为”的场景，比如日志上报、指标采集，丢一两条没关系

设置缓冲区容量要匹配实际吞吐节奏

make(chan int, 100) 创建的是带缓冲的 channel，但缓冲不是万能解药：缓冲区满后仍会阻塞发送，空时仍会阻塞接收。

• 缓冲大小 ≠ 并发数。设成 runtime.NumCPU() 是常见误区；应基于峰值写入速率和下游处理延迟估算
• 若生产者远快于消费者（如秒级产生 10k 事件，消费耗时 100ms），缓冲区很快填满，后续 仍阻塞
• 过度加大缓冲（如 100000）会占用大量内存，且掩盖背压问题，让故障延迟暴露
• 调试时可用 len(ch) 查当前队列长度，cap(ch) 查缓冲容量

用 context 控制超时与取消，防止 goroutine 泄漏

仅靠 select + default 无法处理“等一会儿再试”的需求；真正需要等待时，必须设限。

ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()
select {
case ch <- data:
case <-ctx.Done():
// 超时，放弃发送
log.Println("send timeout:", ctx.Err())
}

• 永远不要在没有超时或取消机制的情况下对 channel 做阻塞操作，尤其在 HTTP handler 或定时任务中
• goroutine 启动后若对 channel 阻塞且无退出路径，它就永远存活，造成泄漏
• context.WithCancel 更适合手动中断（如用户关闭页面），WithTimeout 更适合调用外部服务

缓冲区和 select 都只是工具，关键在理解数据流瓶颈在哪——是生产太快？消费太慢？还是上下游节奏根本错配？这时候可能该换消息队列，而不是把 channel 缓冲调到 10MB。