必须用 Lua 脚本原子执行 INCR + EXPIRE,避免竞态;Redis 操作需绑定请求上下文并设超时;key 应按客户端标识多维设计,禁含动态参数;触发限流返回 429 并正确设置 X-RateLimit-Reset。

频控必须用 Redis INCR + EXPIRE 原子组合,不能只靠 SETNX
单次请求计数+过期设置必须原子执行,否则在高并发下会出现“计数超限但没设过期”或“设了过期但没计数”的竞态。Go-redis/v9 的 client.Incr() 不带 TTL,client.SetNX() 又不支持自增——直接拼两个命令是危险的。
正确做法是用 Lua 脚本封装 INCR 和 EXPIRE 逻辑,确保首次计数时才设过期时间:
if redis.call("INCR", KEYS[1]) == 1 then
redis.call("EXPIRE", KEYS[1], tonumber(ARGV[1]))
end
return redis.call("GET", KEYS[1])
调用时传 []string{key} 和 ttlSeconds(如 60),返回当前计数值;若返回值 > 限流阈值(如 100),就拒绝请求。
- 别把脚本写在 handler 里,应定义为全局常量或用
embed.FS加载,方便审计和热更新 - key 命名建议带前缀和维度,例如
"rate:ip:" + c.RealIP()或"rate:uid:" + userID,避免不同策略互相污染 - 脚本返回
nil或 error 时,应视为计数失败,**默认放行**(宁可漏控,不可误杀)
Echo 中间件里怎么安全传入 context 并控制超时
Redis 操作必须受请求上下文约束,否则慢查询会拖垮整个 handler,甚至引发 goroutine 泄漏。不能直接用 context.Background() 或忽略 ctx。
中间件内应显式传入 c.Request().Context(),并为 Redis 操作加短超时(如 200ms):
ctx, cancel := context.WithTimeout(c.Request().Context(), 200*time.Millisecond)
defer cancel()
result, err := rdb.Eval(ctx, rateScript, []string{key}, ttlSeconds).Int64()
- 超时值不能设成
0或负数,否则WithTimeout会 panic - 别在中间件里裸启 goroutine 做异步频控——频控结果必须同步判断,否则响应头都发出去了才拦住,已无意义
- 如果 Redis 集群偶尔超时,建议 fallback 到本地
sync.Map简单兜底(仅限非核心接口),但需明确标注“降级模式”
怎么设计 key 才避免被绕过或误共享
key 设计决定了频控是否真正生效。常见错误是只按路径限流(如 "rate:/api/order"),结果所有用户共用一个计数器;或者把敏感参数(如 token、sign)明文塞进 key,导致缓存爆炸或信息泄露。
- 优先按客户端标识分组:IP(
c.RealIP())、用户 ID(从 JWT 解析)、设备指纹(如 UA + IP 哈希) - 若需多维组合(如“每个用户每分钟最多调 5 次下单接口”),key 格式推荐
"rate:uid:" + uid + ":path:/api/order",用冒号分隔,语义清晰且易扫描清理 - 绝对不要包含动态参数:
t=、timestamp=、sign=这类每次变化的 query 参数,应提前从 URL 中剥离再构造 key - 对 header 做选择性提取:比如只取
X-App-Version而非整段Authorization,既隔离老版本攻击面,又避免因 token 刷新导致 key 失效
触发限流后怎么返回合理响应而不暴露细节
返回 429 是标准做法,但直接返回 {"error": "too many requests"} 容易被爬虫识别规律;更糟的是把剩余秒数(X-RateLimit-Reset)算错,导致客户端盲目重试。
正确方式是:先用 PTTL 查 key 剩余毫秒数,再转成 Unix 时间戳填入 header:
ttlMs, _ := rdb.PTTL(ctx, key).Result()
if ttlMs > 0 {
resetAt := time.Now().Add(ttlMs).Unix()
c.Response().Header().Set("X-RateLimit-Reset", strconv.FormatInt(resetAt, 10))
}
- 别硬编码
time.Now().Add(60 * time.Second)——实际 TTL 可能因续期或主从延迟而不同 - 响应体尽量简洁,避免带堆栈或内部服务名;生产环境禁用
echo.HTTPError.Message直出 debug 信息 - 高频接口建议加随机抖动(如 ±500ms),防攻击者精准卡窗口重试
真正容易被忽略的是:当 Redis 不可用时,你设的 fallback 行为是否与业务风险等级匹配——支付类接口不该降级,而搜索建议可以;这个决策点不在代码里,而在 SLO 文档中。











