buffered channel 必须配合 select+default 才算真削峰，直接 ch 阻塞写入会导致上游 handler 卡死、连接堆积，最终触发负载均衡器超时踢出节点。
buffered channel 必须配合 select+default 才算真削峰
直接 ch 写入带缓冲的 channel 是危险操作：channel 满时 goroutine 会永久阻塞，HTTP handler 卡住，连接堆积，负载均衡器超时踢出节点。真正起作用的是非阻塞写法：
-
select块中必须包含default分支，写不进就快速失败或降级（如返回 503） - 不能依赖 channel 长度做“限流”，它只控深（最多积压多少请求），不控速（每秒放多少）
- 容量
N要按公式算：P99 处理耗时 × 峰值 QPS × 可容忍积压时长，例如 50ms × 200 QPS × 2s ≈ 400；设小了丢请求，设大了内存爆
RabbitMQ 不是削峰终点，只是下游搬运工
把请求扔进 RabbitMQ 就以为削峰完成？错。它只是把压力从 API 层转移到 MQ 层，上游 HTTP 服务该崩还是崩。RabbitMQ 的 basic.qos 只影响消费者预取量，对 API 层完全无感；队列长度持续上涨但 consumer utilisation 接近 0，说明消费者已断连或处理不过来，而此时 API 早被压垮。
- 必须开启
publisher confirms，否则网络抖动会导致消息静默丢失，上游还误以为成功 - 设置
queue.max-length和queue.overflow = drop-head，防 broker 内存被撑爆 - 消费者端
prefetch count控制在 1~10，避免单个 consumer 积压太多未 ack 消息，拖慢整体吞吐
go-zero 的 rate.Limiter 只能限流，不能削峰
rate.Limiter 是令牌桶实现，超出即刻返回 429 Too Many Requests，不缓存、不排队、不延后——它拒绝洪峰，而非吸收洪峰。削峰的本质是“缓冲+平滑释放”，不是“一刀切拒掉”。所以它适合做第一道闸门（防恶意刷），但不能替代有界缓冲区。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 和 buffered channel 配合使用是合理策略：先用
rate.Limiter拦掉明显异常流量，再用 channel 缓冲剩余合法峰值 - 单独用
rate.Limiter+ RabbitMQ，等于两层拒绝逻辑叠加，没解决“请求来了往哪放”的问题 - 注意
rate.Limiter的AllowN时间窗口要对齐业务 P99，否则窗口错位导致误杀
下游消费 goroutine 必须带 recover 且主动探测连接状态
消费端崩溃不报错、不重连、不告警，是“假削峰”最隐蔽的破口。一旦 RabbitMQ 连接断开，ch 里积压的请求永远没人取，buffered channel 慢慢填满，上游开始 503，而你还在查 MQ 管理界面看 queue length。
立即学习“go语言免费学习笔记（深入）”；
- 每个消费 goroutine 必须包
defer func() { if r := recover(); r != nil { log.Error(r) } }() - 消费循环里要定期调用
channel.IsClosed()或发 probe 请求检测连接健康，断连时暂停读ch、触发告警、等恢复后再 resume - 别依赖
context.WithTimeout就认为安全——超时只管单次消费，不管长连接存活性
真实削峰的关键不在“堆多大 buffer”，而在“buffer 满了怎么办”和“下游断了怎么知”。这两个点漏掉任何一个，整个削峰链路就形同虚设。
