缓冲区大小不直接提升生产者速率，但它决定生产者是否会被迫停等——选错大小，生产者反而卡住，吞吐量掉得比没缓冲还狠；缓冲区为0时生产者必然阻塞，因无缓冲channel要求发送和接收严格配对。
缓冲区大小不直接提升生产者速率，但它决定生产者是否会被迫停等——选错大小，生产者反而卡住，吞吐量掉得比没缓冲还狠。
缓冲区为 0 时生产者必然阻塞
无缓冲 chan int 要求发送和接收严格配对：ch 会一直挂起，直到另一端执行 <code>。这意味着：
- 生产者无法“先发后收”，必须等消费者就绪才能继续
- 哪怕消费者只慢 1ms，生产者就卡 1ms；10 个生产者全堵住，goroutine 积压、调度开销飙升
- 适合强同步场景（如初始化信号、锁步协调），但绝不适合任何需要“攒一批再处理”的流水线
缓冲区过大反而拖慢整体吞吐
看似“越大越不堵”，实际在多数真实服务中会引入三重损耗：
- 内存分配开销：创建
make(chan int, 65536)会一次性分配约 512KB 连续内存（int 占 8 字节 × 65536），GC 压力陡增 - 缓存局部性破坏：大缓冲区跨多个 cache line，频繁读写导致 CPU 缓存失效率上升
- 延迟掩盖问题：生产者狂写，消费者滞后，缓冲区持续堆积 → 最终 OOM 或消息积压数秒甚至分钟，业务 SLA 彻底失控
实测数据表明：当缓冲区从 16 扩到 1024，在日志采集场景下，P99 延迟升高 3.2 倍，而吞吐量仅提升 7%。
立即学习“go语言免费学习笔记（深入）”；
Colly Golang Web Scraper and Crawler Framework
下载
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
按生产/消费速率差动态算缓冲区大小
别拍脑袋设 100 或 1024，用这个公式起步：bufferSize = (prodRate - consRate) × maxDelay
-
prodRate和consRate单位统一为“条/秒”，比如日志系统：生产 800 条/秒，消费 500 条/秒 -
maxDelay是你能容忍的最长积压时间，比如 200ms → 0.2 秒 - 算出来是
(800 - 500) × 0.2 = 60，那就设make(chan []byte, 64)（向上取 2 的幂方便对齐） - 上线后必须监控
len(ch)占比：持续 >80% 就说明消费者跟不上，得扩容消费者或加限流，而不是调大缓冲区
高频小数据场景优先用无缓冲 + select default
比如 HTTP 中间件打点、指标上报这类“丢了也不致命，但不能卡主流程”的操作：
- 直接用
make(chan event, 1)或make(chan event, 0)都行，关键在发送侧加保护 - 永远别写裸
ch ，改用：
select {
case ch <- e:
default:
// 缓冲满或消费者挂了，直接丢弃或降级写本地文件
log.Warn("metrics channel full, dropped")
}这样既避免 goroutine 泄漏，又把缓冲区大小的影响降到最低——它只是防抖的“保险丝”，不是扩容的“水龙头”。
真正卡吞吐的从来不是缓冲区数字本身，而是你没监控 len(ch)、没设 select default、没让缓冲区大小跟着 prodRate 和 consRate 动态漂移。这些细节漏一个，调再大的 buffer 都是给 OOM 提前下单。
