Redis多规则限流与防重复提交需协同实现：限流防过量请求，防重放保请求唯一性；二者必须共享分布式原子状态（如Lua脚本+带身份标识的Redis key），否则单机方案在多实例下失效。
防重放和限流不是两个独立功能，而是一体两面的安全控制：一个管“请求是否合法唯一”，一个管“请求是否过量”。单做任一者都可能被绕过——比如只限流不防重放，攻击者可反复重发同一合法请求；只防重放不限流，一次批量伪造请求就能打满连接池。
为什么直接用 rate.Limiter 会漏掉真实攻击流量
它只在单进程内存中维护令牌桶状态。5个Pod各跑一个 rate.NewLimiter(100, 200)，入口总QPS就是500——这不是bug，是设计使然。但生产环境没人能接受“配置100 QPS，实际放行500”。更隐蔽的问题是：Allow() 非阻塞、不校验上下文，返回false后若没立刻return，业务逻辑照常执行；而硬编码路径（如if r.URL.Path == "/pay"）会让规则散落在代码各处，无法热更新。
- 必须按路由维度缓存
*rate.Limiter实例，key 建议用"service:path"格式（如"payment-svc:/v1/pay"） - 缓存结构用
sync.Map或带sync.RWMutex的 map，避免高并发下 panic - burst 值设为 QPS 的 2–3 倍（如 QPS=100 → burst=200），太小导致正常重试被拒，太大则失去限流意义
- 健康检查路径（如
/healthz）必须显式跳过，否则 K8s probe 反复失败触发滚动重启
防重放不能只靠时间戳，nonce 必须绑定用户+时效
只校验 req.Timestamp 是否在5分钟内，等于给攻击者整整5分钟窗口重放任意合法请求。真正要防的是“同一签名+参数组合只能成功一次”。这要求服务端存储并验证不可复用的状态，且该状态必须与调用方强绑定。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
noncekey 必须含身份标识，如"user:12345:abcde-fghij"，绝不能全局共用 - 存储必须原子：用 Redis 的
SET key value EX 300 NX，NX保证首次写入才成功，EX 300自动过期 - 不要先
GET再SET：中间存在竞态窗口，两个并发请求可能同时判定 nonce 未存在，然后都写入成功 - 本地内存方案仅适用于低QPS内部工具，需用滑动窗口+定时清理，无法杜绝极小概率漏判
分布式场景下限流和防重放必须共享状态
单机 rate.Limiter 和内存 map[string]struct{} 在多实例部署时完全失效。跨Pod的流量控制和 nonce 校验，必须依赖外部存储，且操作需原子化。
立即学习“go语言免费学习笔记（深入）”；
- 限流用 Redis + Lua：脚本必须将“计数+过期设置”合并为单次原子操作，避免
INCR后EXPIRE失败导致 key 永久存在 - key 设计要带精度，如
"limit:ip:192.168.1.100:2026063011"（小时级），比固定窗口更平滑 - 防重放的 Redis key 过期时间（300秒）应 ≥ 网络最大延迟 + 服务最长处理耗时，但不超过业务允许的最大时钟偏差
- Redis 连接池大小要足够，否则限流逻辑本身会成为性能瓶颈
最易被忽略的点是：限流响应头和重放拒绝响应必须标准化。前端或上游网关需要靠 X-RateLimit-Limit、X-RateLimit-Remaining 等头做协同降级；而重放拒绝必须返回明确错误码（如 401 Unauthorized 或自定义 403 Forbidden）和可读 message，不能只抛 panic 或静默丢弃——否则问题排查时连日志都找不到线索。
