fiber框架需通过fiber-rate-limit或golang.org/x/time/rate手动实现限流，因不兼容python生态库且无内置支持；内存模式仅适用于单机，生产环境必须用redis保证多实例一致性。
Fiber 框架本身不内置限流中间件，必须通过第三方库 fiber-rate-limit 或手动集成 golang.org/x/time/rate 实现；直接用 fiber.New() 默认配置无法生效，漏掉存储后端或 key 生成逻辑会导致限流完全失效。
为什么不能直接用 FastAPI 的 slowapi 或 fastapi-limiter？
Fiber 是 Go 语言框架，所有 Python 生态的限流库（如 slowapi、fastapi-limiter）完全不兼容。试图复用其配置方式（比如照搬 "5/minute" 字符串语法）会编译失败或静默跳过限流逻辑。
- Go 没有 Python 那样的装饰器语法，限流必须显式注册为中间件
- Fiber 的中间件签名是
func(*fiber.Ctx) error，而 Python 库返回的是类实例或装饰器函数 - Redis 连接、内存桶初始化、key 提取等步骤在 Go 中需手动构造，无法靠字符串自动解析
用 fiber-rate-limit 快速启用基于 IP 的限流
这是目前最接近 FastAPI + slowapi 体验的方案，支持内存和 Redis 存储，语法简洁。注意：它不是 Fiber 官方维护，但 star 数高、更新活跃（2026 年仍在维护）。
安装：go get github.com/gofiber/fiber-rate-limit
基础用法（内存模式）：
import (
"github.com/gofiber/fiber/v2"
"github.com/gofiber/fiber-rate-limit"
)
<p>app := fiber.New()
app.Use(ratelimit.New(ratelimit.Config{
Next: func(c <em>fiber.Ctx) bool {
return c.IP() == "127.0.0.1" // 可选：跳过本地调试
},
Store: ratelimit.InMemoryStore{ // 内存存储，重启即清空
MaxRequests: 10,
Window: 60, // 秒
},
KeyGenerator: func(c </em>fiber.Ctx) string {
return c.IP() // 用客户端真实 IP 作 key
},
Message: "Too many requests, please try again later.",
}))
</p>
-
Window单位是秒，不是"10/minute"这类字符串 —— 必须拆成MaxRequests=10+Window=60 - 若用 Nginx 反向代理，
c.IP()返回的是 Nginx 地址，需改用c.Get("X-Real-IP")并确保 Nginx 配置了proxy_set_header X-Real-IP $remote_addr; - 内存模式仅适合单机开发；生产环境必须换
ratelimit.RedisStore，否则集群下各实例各自计数，完全失效
用 golang.org/x/time/rate 手写轻量限流中间件
当需要精确控制桶容量、填充速率或做条件限流（如登录用户放宽限制）时，绕过第三方库更可控。核心是每个请求复用一个 *rate.Limiter 实例，不能每次新建。
示例（按 IP 维护独立限流器）：
import (
"sync"
"time"
"golang.org/x/time/rate"
"github.com/gofiber/fiber/v2"
)
<p>var (
limiters = sync.Map{} // map[string]<em>rate.Limiter
limiterRate = rate.Every(1 </em> time.Second) // 每秒 1 个 token
limiterBurst = 5
)</p><p>func rateLimitByIP(c <em>fiber.Ctx) error {
ip := c.IP()
lim, ok := limiters.Load(ip)
if !ok {
lim = rate.NewLimiter(limiterRate, limiterBurst)
limiters.Store(ip, lim)
}
if !lim.(</em>rate.Limiter).Allow() {
return c.Status(fiber.StatusTooManyRequests).SendString("Rate limit exceeded")
}
return c.Next()
}</p><p>app.Use(rateLimitByIP)
</p>
- 必须用
sync.Map或其他并发安全结构缓存各 IP 的*rate.Limiter，否则高并发下 panic -
rate.Every(1 * time.Second)等价于 “每秒 1 次”，不是 “每分钟 60 次” —— 时间单位写错会导致实际限流宽松 60 倍 - 该方案无持久化，重启后所有计数归零；若需跨进程共享，只能上 Redis + Lua 脚本（例如用
redis-go调用INCR+EXPIRE）
真正容易被忽略的是存储一致性：无论选哪种方案，只要部署多实例，就必须用 Redis。内存存储看着简单，上线后发现限流形同虚设，问题往往出在没意识到 Fiber 进程间不共享内存。
