缓冲区大小需根据生产/消费速率差、单条数据大小和内存容忍度综合确定：纯通知用chan struct{}，日志上报设128–1024并批次刷盘，图像帧传输送设4–16配sync.pool复用，突发队列设10–100加select+default限流。
缓冲区大小设多大才不积压又不浪费
没有统一答案，得看生产/消费速率差、单条数据大小、内存容忍度。盲目设 make(chan T, 10000) 很容易把内存吃光，尤其当 T 是含切片或指针的大结构体时。
- 纯通知信号（如 done）用
chan struct{}，零分配 - 日志批量上报：缓冲 128–1024，配合固定大小批次（如每 64 条 flush 一次）
- 图像帧传输：预估单帧最大 size，用
sync.Pool复用[]byte，channel 缓冲只设 4–16，靠 worker 数控节奏 - 突发任务队列：设 10–100，再配
select+default拒绝超额请求，而不是让数据卡在 buffer 里腐烂
发送方卡住？先查是不是没配好接收节奏
缓冲区再大也救不了单个慢消费者。积压本质是消费跟不上，不是 buffer 不够大。
- 别只盯着 channel 容量，检查接收端是否用了阻塞式
而没加超时或 <code>context - 用 worker pool 模式：固定 N 个 goroutine 拉取处理，N 根据 CPU 核心数和任务耗时调优，避免无限起 goroutine 把 buffer 填满后全卡住
- 生产者侧加
select+default：发不出就丢弃或降级（如写本地文件），别死等 - 监控
len(ch)和cap(ch)，接近 90% 就告警，说明消费链路出问题了
range 遍历缓冲通道时为什么程序卡死
因为 range ch 会一直等，直到 channel 关闭。而缓冲通道关不关、谁来关、什么时候关，很容易漏掉。
- 只由唯一发送方（或协调 goroutine）调用
close(ch)，且必须确保所有发送都已完成 - 推荐用
sync.WaitGroup计数生产者：每个 senderdefer wg.Done()，主 goroutinewg.Wait()后再close(ch) - 更健壮的做法是不用
close，改用context.Context控制生命周期，worker 监听ctx.Done()主动退出 - 绝对不要在多个 goroutine 里并发调用
close(ch)—— 会 panic
比加大缓冲区更有效的“防积压”手段
真正稳定的系统，很少靠堆 buffer 解决积压，而是从机制上反压和限流。
- 用带界线的 channel +
context.WithTimeout：发送前select等待，超时就放弃，不把压力传导下去 - 引入 ring buffer 或共享内存替代 channel：比如用
github.com/Workiva/go-datastructures/queue的无锁队列，减少 goroutine 切换开销 - 关键路径上做背压反馈：消费者处理不过来时，通过另一个
chan bool反馈给上游减速，而不是让 buffer 慢慢涨 - 大 payload 场景下，channel 只传指针或 ID，数据走 mmap 或对象池，避免复制和 GC 压力
缓冲区是解耦的润滑剂，不是垃圾场。积压不是 buffer 太小，是上下游节奏没对齐，或是关闭逻辑漏了、超时没设、监控没跟上——这些点比调数字更容易被忽略。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
