Go中channel阻塞需主动避免：无缓冲channel要求send/recv成对发生，否则永久阻塞；常用select+default实现非阻塞操作，但需防CPU空转；缓冲区仅缓解而非解决背压，应依吞吐节奏合理设置；超时与context控制必不可少，以防goroutine泄漏。
channel 阻塞时程序会卡住，必须主动避免
Go 中 chan<int></int> 默认是无缓冲的，send 和 recv 必须成对发生，否则任一端都会永久阻塞。这不是 bug，是设计前提——但实际写业务时，你几乎总需要打破这种强同步约束。
用 select + default 实现非阻塞收发
这是最常用、最轻量的解法。不依赖缓冲区大小，也不改变 channel 语义，只是加一层“尝试”逻辑。
ch := make(chan int)
select {
case ch <- 42:
// 发送成功
default:
// 缓冲满或无人接收，立即返回，不阻塞
}
<p>select {
case x := <-ch:
// 接收成功
default:
// 无数据可读，立即返回
}-
default分支必须存在，否则select会一直等待 - 不能在循环里反复
select+default轮询，容易吃光 CPU；需配合time.Sleep或事件驱动 - 适用于“尽力而为”的场景，比如日志上报、指标采集，丢一两条没关系
设置缓冲区容量要匹配实际吞吐节奏
make(chan int, 100) 创建的是带缓冲的 channel，但缓冲不是万能解药：缓冲区满后仍会阻塞发送，空时仍会阻塞接收。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 缓冲大小 ≠ 并发数。设成
runtime.NumCPU()是常见误区；应基于峰值写入速率和下游处理延迟估算 - 若生产者远快于消费者（如秒级产生 10k 事件，消费耗时 100ms），缓冲区很快填满，后续
仍阻塞 - 过度加大缓冲（如
100000）会占用大量内存，且掩盖背压问题，让故障延迟暴露 - 调试时可用
len(ch)查当前队列长度，cap(ch)查缓冲容量
用 context 控制超时与取消，防止 goroutine 泄漏
仅靠 select + default 无法处理“等一会儿再试”的需求；真正需要等待时，必须设限。
立即学习“go语言免费学习笔记（深入）”；
ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()
<p>select {
case ch <- data:
case <-ctx.Done():
// 超时，放弃发送
log.Println("send timeout:", ctx.Err())
}- 永远不要在没有超时或取消机制的情况下对 channel 做阻塞操作，尤其在 HTTP handler 或定时任务中
- goroutine 启动后若对 channel 阻塞且无退出路径，它就永远存活，造成泄漏
-
context.WithCancel更适合手动中断（如用户关闭页面），WithTimeout更适合调用外部服务
缓冲区和 select 都只是工具，关键在理解数据流瓶颈在哪——是生产太快？消费太慢？还是上下游节奏根本错配？这时候可能该换消息队列，而不是把 channel 缓冲调到 10MB。
