合理设置channel缓冲容量、用select+default避免阻塞、批量传输减少开销、关闭前确保发送完成并用range安全接收。
合理设置channel容量，避免无缓冲导致的频繁阻塞
无缓冲channel（make(chan int)）在每次发送和接收时都需双方goroutine同时就绪，极易引发阻塞。若生产者快于消费者，或存在突发流量，goroutine会挂起等待，降低吞吐。建议根据业务场景预估峰值流量与处理延迟，设置适当缓冲容量。例如日志采集场景中，每秒最多写入1000条日志，单次消费耗时约10ms，则缓冲区设为100–200足够应对短时抖动：logs := make(chan *LogEntry, 150)。注意：缓冲区不是越大越好，过大会占用过多内存，且掩盖设计缺陷（如消费者长期滞后）。
用select + default避免死等，提升响应灵活性
直接对channel执行或<code>ch 会永久阻塞，影响goroutine调度。应结合<code>select语句加default分支实现非阻塞操作或超时控制。例如向监控上报指标时，若通道满则丢弃旧数据而非卡住：
select {<br> case metricsChan <- m:<br> // 成功发送<br> default:<br> // 缓冲满，跳过，不阻塞主流程<br>}
也可搭配time.After做超时降级：case 。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
批量传输代替逐条收发，显著降低调度与拷贝开销
频繁发送小数据（如单个int、string）会触发大量goroutine切换和内存分配。应将多个数据打包成切片统一传递。例如传感器数据采集可改为每10ms聚合一批后发送：
- 消费者端定义：
type Batch struct { Data []float64; Timestamp int64 } - 生产者累积后一次性写入：
ch - 减少channel操作次数达10–100倍，同时降低GC压力
注意：批量大小需权衡延迟与吞吐，通常20–200个元素较均衡；若数据结构较大，考虑复用sync.Pool管理批次对象。
关闭channel前确保所有发送完成，并用range安全接收
未关闭的channel无法通过range自动退出，易造成goroutine泄漏；提前关闭又可能丢失数据。正确做法是：由发送方在完成所有发送后调用close(ch)，接收方用for v := range ch安全遍历——该语法会在channel关闭且缓冲清空后自动退出。避免混用与<code>range，也不要在多协程并发关闭同一channel。若需通知“停止接收”，可额外引入done chan struct{}配合select判断。
