必须用 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 文档中。
