限流装饰器必须支持运行时开关控制，开关状态需用atomic.bool或sync.rwmutex保护，enable/disable方法封装，wait前判断开关并跳过限流逻辑，避免panic和请求丢失。
限流装饰器必须支持运行时开关控制
硬编码开启/关闭限流等于放弃弹性调控能力。真实服务需要根据负载、灰度阶段或故障状态动态启停限流，不能靠重启或改配置。关键不是“能不能限”，而是“什么时候限、对谁限、限多少”能由外部信号决定。
常见错误是把 rate.Limiter 实例写死在闭包里，或者用全局布尔变量控制但没做并发安全处理——多个 goroutine 同时读写开关变量会引发竞态。
- 开关状态必须用
atomic.Bool或sync.RWMutex保护 - 限流器实例仍需按业务粒度独立创建，不能多个接口共用一个
rate.Limiter - 开关逻辑要放在
Wait()调用前，避免无谓的上下文等待开销
带开关的限流装饰器签名怎么设计
函数签名必须暴露开关控制入口，同时保持与原始 handler 兼容。HTTP 场景下最稳妥的是复用标准 func(http.Handler) http.Handler 模式，额外提供一个可变的开关句柄。
别把开关塞进 handler 内部闭包——那样每次调用都要重新构造装饰器，失去复用性；也别用全局变量传参，破坏封装。
- 推荐用结构体封装：包含
*rate.Limiter、atomic.Bool开关、以及可选的http.Handler转发逻辑 - 提供
Enable()/Disable()方法，而非直接暴露原子变量 - 装饰器工厂函数返回闭包时，捕获的是结构体指针，不是值拷贝
限流开关生效时要注意哪些边界
开关关闭后，limiter.Wait(ctx) 这行不能跳过——否则会 panic，因为 nil 指针调用 Wait 会崩溃。也不能直接 return，那样会跳过原 handler 执行。
更隐蔽的问题是：开关从开切到关时，正在排队的请求可能还在等 Wait() 返回，此时若立即关掉限流器，这些请求会被卡住或超时。
- 开关关闭时应允许已进入
Wait()的请求继续完成，不中断当前等待队列 - 建议在
Wait()前加判断：if !d.enabled.Load() { return next.ServeHTTP(w, r) } - 若需立即中断排队，得调用
limiter.ReserveN()并主动Cancel()，但代价高，慎用 - 开关状态变更日志必须打，否则线上排查时无法确认限流是否真被关闭
如何验证开关是否真正起效
光看日志或监控图表不够。限流开关容易“看起来关了，其实还在生效”，尤其当多个装饰器嵌套或限流器被复用时。
最直接的验证方式是构造压测请求，观察响应延迟和 rate.ErrLimited 出现频率；但更可靠的是在装饰器内部埋点，统计每秒实际进入 Wait() 的次数和跳过次数。
- 用
expvar.Int或 Prometheus counter 记录wait_called和wait_skipped - 开关关闭后，
wait_called应趋近于 0，wait_skipped应持续上升 - 注意：不要在开关判断里加锁再读计数器，否则高并发下锁争用反而成为瓶颈
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
