buffered channel 不是自动限流器，仅是固定容量队列；缓冲区满后发送阻塞，导致上游卡死、雪崩风险放大；需显式设定容量n（最大积压量，非并发数），且无超时机制。
为什么用 buffered channel 做流量削峰容易失效
它不是“自动限流器”，只是个带缓冲的队列。一旦生产者持续高速写入、消费者处理跟不上，缓冲区填满后 send 就会阻塞——这在微服务调用链里等于直接卡死上游，反而放大雪崩风险。
- 缓冲区大小必须显式设定，
make(chan T, 0)是无缓冲，make(chan T, N)才是带缓冲，N 不是并发数，而是「最大积压量」 - 没有超时机制：上游发消息时若 channel 满了，
ch 会永久阻塞，除非加 <code>select+default或time.After - 不感知下游健康状态：消费者 panic 或重启后，channel 还在收，消息全丢进缓冲区直到溢出（其实不会溢出，但后续 send 阻塞）
如何让 buffered channel 真正扛住突发流量
核心是把 channel 当作「有界缓冲区」用，而非通信原语。必须配合非阻塞发送、背压反馈、消费保活三件套。
- 上游发送务必用
select包裹，加default分支快速失败，或加time.After控制等待上限：select { case ch <- req: // 成功入队 default: // 缓冲区满，拒绝请求（返回 429 或降级） } - 下游消费者必须持续运行，建议用
for range ch循环，且内部 recover panic，避免 goroutine 意外退出导致 channel “假死” - 缓冲区容量 N 要按 P99 处理耗时 × 峰值 QPS × 可接受积压时长估算，别拍脑袋设 1000；比如平均处理 50ms，峰值 200 QPS，容忍 2 秒积压 → N ≈ 200 × 2 = 400
和 semaphore、rate.Limiter 的关键区别在哪
Buffered channel 削的是「瞬时队列深度」，不是「请求速率」。它不控制每秒多少次调用，只控制最多积压多少待处理任务。
-
golang.org/x/time/rate.Limiter控制请求发放节奏（token bucket），适合 API 网关层限流，但不解决后端处理慢导致的消息堆积 -
golang.org/x/sync/semaphore控制并发数，适合限制同时处理的任务数，但没缓冲——请求来时若没信号量，只能立刻拒绝 -
buffered channel是唯一能「暂存+排队+顺序处理」的原生方案，但必须自己实现超时、拒绝、监控逻辑
线上踩过的坑：缓冲区泄漏和 goroutine 泄漏
最隐蔽的问题不是 channel 满，而是消费者停了但生产者还在发——这时所有 ch 在 <code>select 里走 default 还好；如果忘了加 default，goroutine 就永远卡在那行，内存和 goroutine 数缓慢上涨。
立即学习“go语言免费学习笔记（深入）”；
- 永远不要在循环外创建 channel 后长期复用，尤其跨 HTTP handler；每次请求新建 channel + worker 是反模式
- 用
runtime.NumGoroutine()和pprof定期看 goroutine profile，重点查阻塞在chan send的堆栈 - 给 channel 加名字（通过封装 struct 字段）或日志上下文，否则 panic 时根本分不清是哪个业务 channel 卡住了
实际跑稳的关键不在 channel 多大，而在你有没有在 send 失败时做决策、有没有在 consumer 异常时告警、有没有把缓冲区当临时存储而不是无限蓄水池。这些地方一松懈，削峰就变堵峰。
