无缓冲channel在高并发写入时会卡死，是因为其要求发送与接收goroutine必须严格同步配对：发送操作会永久阻塞直至有接收者就绪，若消费者（如worker）延迟或积压，生产者即全部阻塞，导致链路雪崩。
缓冲 chan 不是“加了就快”，而是解耦生产与消费节奏的关键开关；设错大小反而拖慢吞吐、吃光内存。
为什么无缓冲channel在高并发写入时会卡死
无缓冲 chan 要求发送和接收 goroutine 严格配对——ch 会一直阻塞，直到有另一个 goroutine 正好执行 <code>。当消费者（比如磁盘写入）变慢，所有生产者立刻停摆，CPU 空转，吞吐归零。
- 典型现象：
pprof显示大量 goroutine 卡在chan send状态，runtime.gopark占比超高 - 日志里看不到错误，但 QPS 断崖下跌，且不随 goroutine 数量增加而恢复
- 哪怕只开 1 个写入 goroutine，只要用的是
make(chan []byte)（无缓冲），它就等同于同步串行写
缓冲大小怎么选：看单条数据体积和内存余量
缓冲区不是越大越好。它本质是一块预分配的堆内存，容量 × 单条数据大小 = 实际内存占用。设大了可能 OOM；设小了又起不到缓冲作用。
- 日志类场景（每条
[]byte平均 2–5 KB）：用make(chan []byte, 2048)，约占用 4–10 MB，稳妥 - 大块导出（CSV 分片、Protobuf 序列化结果，单条常 > 1 MB）：用
make(chan []byte, 32)更安全，避免一次占满几百 MB - 绝对不要用
make(chan []byte, 0)或裸make(chan []byte)做异步写入通道——这等于没解耦 - 临界值参考：实测中缓冲 ≥ 1000 后吞吐提升趋缓，但内存线性增长，边际收益快速下降
只加缓冲还不够：必须配批量写 + 主动 fsync
即使用了 make(chan []byte, 2048)，如果消费者还是每次从 channel 拿一条就 file.Write 一次，系统调用开销仍占大头，SSD 写入能力根本跑不满。
- 攒批策略：用
bytes.Buffer或切片拼接，达到阈值（如 128 KB）或 channel 关闭时再 flush -
fsync控制：每写满 1 MB 或每 100ms 主动file.Sync()一次；完全不 sync 会丢数据，次次都 sync 又退化成同步写 - 务必检查
file.Write返回的n, err，忽略err是静默丢数据的常见原因 - 消费者 goroutine 必须
defer close(out)（若需下游继续消费），否则 range 会永远阻塞
真正卡吞吐的往往不是 channel 本身，而是缓冲大小、批量策略、fsync 频率三者没对齐——比如缓冲设了 4096，但消费者每 10KB 就刷一次盘，实际缓冲利用率不足 1%。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
