rate.Limiter 不能直接限制并发数，它基于令牌桶控制单位时间调用次数，不统计或阻塞活跃 goroutine；需用 semaphore.Weighted 或信号量机制实现真正的并发控制。
rate.Limiter 能不能直接限制并发数
不能。rate.Limiter 本质是令牌桶，只管「单位时间放行多少次」，不管当前有多少请求在跑。它不维护 goroutine 状态，也不阻塞或统计活跃连接——所以你用 rate.NewLimiter(10, 5) 控制的是每秒最多 10 次调用，不是最多 10 个并发。
如果你要硬控并发量（比如最多同时处理 3 个 HTTP 请求），得配合 semaphore.Weighted（Go 1.21+）或自己用 sync.WaitGroup + chan struct{} 做信号量。rate 包只负责“节奏”，不负责“人数”。
- 误以为
limiter.Wait(ctx)能拦住第 11 个 goroutine 同时执行？错——它只是让第 11 次调用等，但 goroutine 早已启动 - HTTP handler 里只套一层
limiter.Wait，结果后端服务还是被打挂，因为并发峰值没被削平 - 真正要压并发，得在进 handler 前就卡住，比如用
semaphore.Acquire配合超时 ctx
Wait 和 TryWait 的区别和选哪个
Wait 会阻塞直到拿到令牌（或 ctx 超时），TryWait 立即返回 bool：true 表示抢到了，false 表示桶空了、不等。
选哪个取决于你的错误容忍策略：要保响应延迟就用 TryWait，快速失败；要保成功率且能接受小延迟就用 Wait。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
TryWait适合 API 网关场景：桶空了直接返回429 Too Many Requests，不排队 -
Wait适合后台任务调度：允许短时间积压，但必须全处理完，比如日志投递协程 - 注意
Wait在高负载下可能累积大量等待 goroutine，引发内存上涨，别无脑用 -
WaitN(ctx, n)和TryWaitN(n)支持一次取多个令牌，适合批量操作，但 n 超过 burst 容易失败
burst 参数设太大会导致什么问题
burst 是令牌桶的“容量”，也就是桶最多存几个令牌。设太大（比如 rate.NewLimiter(rate.Every(time.Second/10), 100)）会让限流形同虚设——前 100 次请求几乎不被限，瞬间打满下游。
它不是缓冲队列，而是“突发许可额度”。真实流量突增时，burst 会一次性被清空，之后才开始按 rate 匀速补充。
- 常见错误：把 burst 当成最大并发数设成 1000，结果压测一上来就 1000 QPS 直冲 DB
- 合理做法：burst ≈ rate × 期望最大突发时长。比如想扛住 2 秒内双倍流量，rate=10/s，burst 设 20 就够
- burst 过大还会掩盖真实瓶颈——你以为系统撑住了，其实是限流器没起作用
- 调试时可临时设 burst=1，看是否真被限；再逐步放大，观察下游指标变化
HTTP middleware 里怎么安全集成 limiter
每个请求都调 limiter.Wait(r.Context()) 是基本操作，但容易漏掉两点：panic 恢复后的重复调用、中间件顺序错位。
关键不是“加不加”，而是“在哪加、加几次、失败后怎么兜底”。
- 务必放在所有可能 panic 的中间件之前（比如 recover 中间件之后加限流，panic 后可能又走一遍 limiter）
- 不要在多个中间件里重复调
Wait，否则一次请求扣多次令牌 - 错误响应要带明确 header：
w.Header().Set("X-RateLimit-Remaining", strconv.Itoa(int(limiter.Burst()-limiter.ReserveN(time.Now(), 1).Delay())))—— 实际别这么算，用limiter.Limit()和自定义计数更稳 - 测试时用
httptest.NewRequest+context.WithTimeout模拟超时，验证Wait是否真返回 error
rate 包本身很轻，但组合使用时边界条件多：ctx 取消时机、burst 和 rate 的比例、与其它同步原语的协作……最容易忽略的是——你限的到底是「请求频率」，还是你以为的「资源占用强度」。后者往往得靠更上层的控制手段来补。
