带缓冲通道只是有界队列，不是限流器；n 表示最大积压量而非并发数，超 n 时写入阻塞，仅提供暂存能力，不主动控制速率或拒绝请求。
带缓冲通道不是限流器，只是有界队列
很多人误以为 make(chan T, N) 是个“自动限流开关”，其实它只是个固定容量的内存队列。N 不是并发数，而是最大积压量——超过这个数，ch 就会阻塞。而阻塞在 HTTP handler 里等于卡死 goroutine，直接放大雪崩风险。
- 缓冲区满后，发送操作永久阻塞，除非你主动加控制逻辑
- 它不感知下游是否存活：消费者 panic 或 RabbitMQ 断连，channel 照收不误，消息全堆在内存里
- 没有超时、没有重试、没有状态反馈，纯靠开发者补全
必须用 select + default 避免阻塞
在接口 handler 里直接写 ch 是危险操作。正确姿势是用 <code>select 做非阻塞写，失败立刻降级，不拖慢响应。
select {
case ch
-
default分支是关键，它让写入变成“尽力而为”，而非“必须成功” - 别用
time.After做超时——瞬时洪峰下，等待毫无意义，快速失败才是削峰前提 - 降级逻辑要轻量，避免引入新瓶颈（比如写磁盘也要加限速和 rotate）
消费者必须保活并反馈下游健康状态
消费者 goroutine 如果 panic 退出，ch 就成了单向漏斗：上游还在写，下游已停摆。这比没缓冲更糟——所有积压都闷在内存里。
- 消费者必须用
for range ch循环，并在循环内recover() - 每次 publish 前检查 RabbitMQ 连接状态，断连时暂停读取、触发告警，而不是硬塞
- 配合 RabbitMQ 的
publisher confirms，确保消息真正落盘，否则网络抖动会导致“假成功” - 消费速率要可调：可通过动态增减 goroutine 数量，或基于当前 channel 长度做自适应扩缩
缓冲容量 N 要按 P99 × QPS × 时长算，不是拍脑袋
设 N=1000 看着很“安全”，但若实际 P99 耗时 80ms、峰值 QPS 300、容忍积压 1.5 秒，理论积压上限只有 300 × 1.5 = 450。多出来的 550 容量纯属冗余，还浪费内存。
- 公式：
N ≈ 峰值 QPS × 可容忍积压时长（秒），其中“峰值 QPS”建议取最近 7 天 P99 流量 × 1.2 安全系数 - 如果下游处理耗时波动大（比如依赖外部 API），要把 P99 耗时代入计算，而非平均值
- 上线后监控
len(ch)和cap(ch)比值，持续高于 80% 就该扩容或优化消费逻辑
真正难的不是写对 make(chan, N)，而是让整个链路——从 HTTP 入口、buffered channel、异步 publish、RabbitMQ 配置到消费者保活——形成闭环背压。少一环，削峰就变成“假装削峰”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
