Golang接口防刷方法与限流策略

golang.org/x/time/rate 是最常用、标准库生态支持最好的令牌桶限流方案，适合 per-IP 或 per-token 限流，需避免全局共享 limiter、正确设置 rate 和 burst 参数，并结合中间件、Redis 分布式存储及多层防护实现生产级限流。

用 golang.org/x/time/rate 做简单令牌桶限流

直接上手最常用、标准库生态支持最好的方案：标准的令牌桶（Token Bucket）限流。它适合控制单个用户或 IP 的请求速率，比如“每秒最多 5 次”或“每分钟最多 100 次”。rate.Limiter 是线程安全的，可复用，也支持阻塞/非阻塞模式。

常见错误是把 rate.NewLimiter 实例全局共享却没区分限流维度（比如所有请求共用一个桶），结果变成全站总限流，而非 per-IP 或 per-token 限流。

• 每个客户端应持有独立的 *rate.Limiter，通常按 IP 或 Authorization token 做 key 存在内存 map 或 Redis 中
• 初始化时注意两个参数：rate.Limit（每秒放行数）和 burst（桶容量），burst 决定了突发流量能扛多少，设太小会导致正常抖动也被拒
• 调用 limiter.Allow() 判断是否放行，返回 false 时应立即返回 HTTP 429 Too Many Requests

limiter := rate.NewLimiter(rate.Every(1*time.Second), 5) // 每秒 5 个，桶容量 5
if !limiter.Allow() {
    http.Error(w, "too many requests", http.StatusTooManyRequests)
    return
}

用中间件封装限流逻辑，避免重复写判断

限流不是只加在某个 handler 里，而是要作为 HTTP 中间件统一注入。Golang 的 http.Handler 链式结构天然适合做这件事，但要注意中间件里不能直接用闭包捕获局部变量来存 limiter —— 它会跨请求复用，导致限流失效或误杀。

典型陷阱是这么写：

func RateLimitMiddleware(next http.Handler) http.Handler {
    limiter := rate.NewLimiter(rate.Every(1*time.Second), 10)
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        if !limiter.Allow() { // ❌ 全局 limiter，所有请求共用一个桶
            http.Error(w, "429", http.StatusTooManyRequests)
            return
        }
        next.ServeHTTP(w, r)
    })
}

正确做法是：从请求中提取标识（如 r.RemoteAddr 或解析 header 中的 X-Forwarded-For / Authorization），再查或新建对应 limiter。可用 sync.Map 做轻量级内存缓存（适合中小流量），高并发建议用 Redis + Lua 原子操作。

防刷不只是限流：必须配合 IP 黑名单与请求特征识别

单纯限流挡不住代理池、傀儡机群或参数遍历类攻击（比如暴力扫 /api/user?id=1~999999）。这时需要更主动的防护层：

• 记录高频异常行为：连续 3 次 404、500 或空 body POST，自动加入临时黑名单（比如 10 分钟）
• 检查 User-Agent 是否为空或明显异常（如 python-requests 无 Referer 且高频）
• 对敏感接口（如登录、短信发送）强制加验证码或设备指纹（如 Sec-Ch-Ua + UA + IP 组合哈希）
• 用 net/http 的 Request.Context() 带上标记，方便后续日志归因或熔断决策

别依赖前端传的 X-Real-IP 做唯一标识 —— 它可被伪造；后端应以 r.RemoteAddr 为基础，结合反向代理（如 Nginx）真实头配置（set_real_ip_from）来还原可信 IP。

生产环境必须考虑分布式与持久化问题

单机 sync.Map 在多实例部署下完全失效。一旦服务横向扩容，每个节点都有自己的 limiter，攻击者只要轮询不同实例就能绕过限流。解决方案只有两个方向：

• 用 Redis 实现中心化限流：推荐 redis-cell 模块（原生支持漏桶），或用 Lua 脚本保证 INCR + EXPIRE 原子性（key 为 "rate:ip:192.168.1.100:1m"）
• 用一致性哈希把同一 IP 映射到固定节点（如 hash(ip) % node_count），适合无状态服务，但扩缩容时有部分 key 失效风险

Redis 方案还要注意连接池设置和超时 —— 限流逻辑不能因为 Redis 延迟而拖慢整个响应。建议设 context.WithTimeout 控制 Redis 调用，超时则降级为本地 limiter（允许少量漏放，不阻塞主流程）。

真正难的不是实现限流，而是怎么定义“异常”：同一个 IP 同时刷登录和下载接口，是封整个 IP，还是只封登录？要不要区分内网/外网？这些策略没法靠代码自动决定，得靠日志聚合 + 告警 + 人工运营闭环。