rate.limiter是go单机限频首选，需为每个ip/用户id动态创建独立实例，用sync.map缓存，非阻塞调用allow()或reserven()，禁用wait()和默认日志。
用 rate.Limiter 做单机限频最稳
敏感接口（如登录、密码重置、短信发送）必须做请求频率控制，而 Go 标准库的 rate.Limiter 是首选——它基于纳秒级单调时钟、线程安全、开销仅 10–50ns，比手写计数器或依赖 Redis 更轻量可靠。别被“分布式”带偏：95% 的敏感接口限频场景，单机控制就足够，加 Redis 反而引入网络延迟和故障点。
常见误配：rate.NewLimiter(10, 1) → 突发流量直接全拒，连健康检查都可能失败；合理值应是 Burst ≥ Limit，且 Burst 通常设为平均 QPS 的 2–3 倍（如预估登录接口峰值 30 QPS，可设 rate.NewLimiter(10, 30)）。
注意：rate.Every(100 * time.Millisecond) ≈ 10 QPS，别把 Every 当整数 QPS 直接填进去。
按 IP 或用户 ID 动态创建限速器实例
不能全局只用一个 *rate.Limiter，否则所有请求挤同一桶，起不到“按来源隔离”的作用。必须为每个 key（如客户端 IP、用户 token）维护独立实例。
- 别直接用
c.IP()或c.Request.Header.Get("X-Forwarded-For")当 key —— 经过 Nginx 或云 WAF 后可能全是内网地址或空值；优先取c.Get("X-Real-IP")， fallback 到c.IP() - 用
sync.Map缓存限速器：limiterMap.LoadOrStore(ip, rate.NewLimiter(limit, burst))，避免高频新建对象 - key 命名建议加前缀，比如
"login:" + ip，方便后续清理或监控
在 Fiber 中间件里非阻塞调用 Allow() 或 ReserveN()
HTTP 接口必须用非阻塞方式限流，否则客户端超时、连接堆积、goroutine 泄漏风险极高。不要用 Wait()，除非你明确传了带 deadline 的 context.Context。
推荐做法：
- 对普通敏感接口（如 POST /login），用
limiter.Allow()快速判断：返回false就立刻c.Status(429).SendString("too many requests")并return - 对单次请求需消耗多个 token 的场景（如文件分片上传校验），改用
limiter.ReserveN(time.Now(), n)预占，再调res.OK()判断是否成功；失败则调res.Cancel()归还 - 拒绝请求后必须
return，绝不能跟c.Next()—— 响应已发出，Fiber 会终止链路，后续 handler 不会执行
上线前必须关掉 fiber.Default() 和默认日志
限频中间件若跑在 fiber.Default() 上，每秒几百次 429 日志会直接压垮磁盘 I/O，TTFB 增加 0.3–0.8ms，高并发下雪崩风险陡增。
正确初始化方式：
- 用
fiber.New(&fiber.Config{DisableStartupMessage: true, EnablePrintRoutes: false})启动空应用 - 手动加必要中间件，如
recovery.New()，但禁用logger.New() - 若真要记录限频事件，只记 error 级别，且异步写入（如通过 channel + worker goroutine），不直写 stdout/stderr
真正容易被忽略的是：限频逻辑一旦嵌入业务 handler 内部（而非中间件），就无法复用、难测试、易遗漏；所有敏感路径必须统一走同一个限频中间件，靠路由前缀（如 /api/v1/auth/）或 method+path 组合精确拦截。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
