优化 channel 性能关键在“何时发、发多少、谁在等”：无缓冲 channel 易阻塞，有缓冲需按批次大小×1.5~2 倍设容量（如 10~20），避免过小仍阻塞或过大掩盖消费慢问题，并防范 goroutine 泄漏与空转。
Go 中 channel 是协程间通信的核心机制，但用不好反而成为性能瓶颈。优化 channel 传输性能，关键不在“怎么发”，而在“何时发、发多少、谁在等”。阻塞往往源于容量设计失当、协程调度不均或数据流错配，而非 channel 本身慢。
合理设置缓冲区容量，避免无谓阻塞
无缓冲 channel（make(chan T)）要求发送和接收必须同步完成，任何一方未就位就会立即阻塞。高吞吐场景下极易卡住生产者。有缓冲 channel（make(chan T, N)）可解耦生产和消费节奏，但容量不是越大越好。
- 容量过小（如 1~8）：几乎等效于无缓冲，仍频繁阻塞
- 容量过大（如 10000+）：内存占用高，且掩盖了消费者处理慢的真实问题
- 推荐做法：按典型批次大小 × 1.5~2 倍预估，例如每秒产出 100 条日志，消费者平均处理延迟 50ms，则缓冲区设为 10~20 即可覆盖抖动
避免 goroutine 泄漏与空转等待
channel 阻塞常伴随 goroutine 积压——比如消费者崩溃后未关闭 channel，生产者持续写入直至缓冲区满；或用 for range ch 读取已关闭但仍有残留数据的 channel，导致提前退出漏处理。
- 发送端加超时：
select { case ch - 接收端检查是否关闭：
if v, ok := ，不要依赖 range 自动退出 - 用
sync.WaitGroup或context显式控制生命周期，尤其在启动多个消费者时
减少跨 goroutine 数据拷贝与序列化开销
channel 传递结构体时，默认是值拷贝。若结构体大（如含 []byte、map 或嵌套指针），每次发送都触发内存分配与复制，性能断崖式下降。
立即学习“go语言免费学习笔记（深入）”；
- 传指针而非值：
chan *Request比chan Request更轻量（注意并发读写安全） - 复用对象：用
sync.Pool缓存高频创建的结构体，发送前pool.Put()，接收后pool.Get() - 避免在 channel 中传 JSON 字符串等中间格式，直接传结构体或预序列化后的字节切片
用 select + default 避免盲等，让逻辑更可控
单纯 会永久阻塞，而 select 提供非阻塞/限时选择能力，是应对不确定性的标准姿势。
- 非阻塞尝试：
select { case v := - 带超时的等待：
select { case v := - 多 channel 路由：
select { case a := ，天然支持优先级与扇入（fan-in）
基本上就这些。channel 不是万能管道，而是需要配合业务节奏精细调节的协作契约。不复杂但容易忽略——调优重点从来不在语法，而在理解谁在等、等多久、等什么。
