带缓冲 channel 的容量应基于峰值qps×平均处理耗时估算瞬时积压上限，再乘以2–3倍安全系数设定初始值，上线后监控len(ch)水位持续＞80%需扩容或优化消费者。
带缓冲 channel 的容量怎么设才不卡又不爆内存
缓冲大小不是拍脑袋定的，它直接决定背压是否生效、goroutine 是否堆积、内存是否被吃光。设太小（比如 make(chan int, 1)）和无缓冲几乎没区别，生产者一快就阻塞；设太大（比如 make(chan int, 100000)）看似吞吐高，实际延迟不可控，还可能触发 GC 频繁抖动。
- 先估算峰值每秒数据量 × 处理单条平均耗时 → 得到瞬时积压上限（例如：500 QPS × 20ms = 10 条）
- 再乘以安全系数 2–3 倍，作为缓冲初始值（如
make(chan *Request, 32)） - 上线后监控
len(ch)占比，持续 >80% 就说明缓冲不足或下游处理慢，得调大或优化消费者逻辑 - 别用
cap(ch)当指标——它固定不变，真正关键的是len(ch)动态水位
select + default 是防卡死的标配写法
纯 或 <code>ch 在下游慢或 channel 满时会永久阻塞，这是高并发服务里最常见 panic 来源之一。必须用非阻塞方式兜底。
- 发送时加
default分支，失败就丢弃、重试或降级：select { case ch - 接收时同理，避免 goroutine 卡在空闲 channel 上：
select { case data := - 如果业务不能丢数据，就改用带超时的
select+time.After，但注意别让超时 channel 泄漏
关闭 channel 前必须确认所有发送者已退出
向已关闭的 channel 发送数据会 panic；从已关闭且无数据的 channel 接收会立即返回零值——这本身没问题，但误判关闭时机就会导致数据丢失或崩溃。
- 只由发送方负责关闭，接收方永远只读不关
- 多个 goroutine 向同一 channel 发送？用
sync.WaitGroup等所有发送者结束再 close - 别依赖
defer close(ch)在 goroutine 里——万一它提前 return，channel 就早关了 - 典型错误：
for range ch会自动在 channel 关闭后退出，但若发送方还没 finish 就 close，后面的数据就没了
任务合并（coalescing）比盲目扩 buffer 更治本
当大量请求重复处理相同 ID 数据（比如查同一用户资料），靠加大 buffer 只是把压力往后推，根本没减少计算量。这时候该用 coalescing，让同 key 请求共享一次结果。
- 核心结构是
map[string]*pendingGroup，每个 key 对应一个等待队列和一个正在执行的 goroutine - 新请求进来先查 map：有 pending 就 append 到其
waitersslice；没有就新建并启动 goroutine 执行真实逻辑 - 执行完后遍历所有 waiter，统一通知结果 —— 这比开 100 个 goroutine 查 100 次数据库强得多
- 注意用
sync.Map或分片锁保护 map，避免高并发下写冲突
真正难的不是写对 channel 语法，而是判断什么时候该让它堵、什么时候该让它流、什么时候干脆绕开它另起炉灶。缓冲只是表象，背后全是吞吐和延迟之间的具体权衡点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
