Go语言Gin框架中基于内存的简易限流器实现-Golang-PHP中文网

gin 中直接用 time.sleep 或全局计数器限流会因并发不安全导致 map 冲突、计数丢失和 goroutine 阻塞，正确做法是使用 golang.org/x/time/rate.limiter 实现线程安全的令牌桶限流，并按 ip 或路径等维度独立维护 limiter 实例，配合 sync.map 缓存与 ttl 清理。

go语言gin框架中基于内存的简易限流器实现

为什么 Gin 里直接用 `time.Sleep` 或全局计数器做限流会出问题

因为并发不安全，且无法按 IP、路径等维度隔离统计。Gin 的 handler 是并发执行的，多个请求同时读写同一个 map 或变量，会导致 fatal error: concurrent map read and map write。更糟的是，没加锁时计数可能丢失，实际 QPS 远超预期。

别用未加锁的 sync.Map 或普通 map 存计数 —— sync.Map 不支持原子增减，得自己套 sync.Mutex
别在 handler 里直接调用 time.Sleep 模拟限流 —— 阻塞协程，浪费 goroutine 资源
别把限流逻辑写死在路由里 —— 复用性差，不同接口要重复写

用 `golang.org/x/time/rate` 实现线程安全的内存限流中间件

rate.Limiter 是 Go 官方维护的令牌桶实现，轻量、无依赖、并发安全，适合单机场景。它不依赖外部存储，所有状态都在内存中，响应快，但重启后计数清零 —— 这对很多内部服务或开发环境是可接受的。

每个限流策略对应一个独立的 *rate.Limiter 实例，避免多路复用冲突
推荐按 IP + path 组合键生成 limiter（用 sync.Map 缓存），而不是全局一把锁
注意 limiter.Allow() 返回 false 时应立即返回 429 Too Many Requests，不要继续执行业务逻辑

// 示例：按 IP 限流，每秒最多 5 次
func RateLimitByIP() gin.HandlerFunc {
    limiterMap := sync.Map{} // key: ip, value: *rate.Limiter
    limit := rate.Limit(5)
    burst := 5

    return func(c *gin.Context) {
        ip := c.ClientIP()
        limiter, _ := limiterMap.LoadOrStore(ip, rate.NewLimiter(limit, burst))
        if !limiter.(*rate.Limiter).Allow() {
            c.AbortWithStatusJSON(http.StatusTooManyRequests, gin.H{"error": "rate limit exceeded"})
            return
        }
        c.Next()
    }
}