秒杀接口必须在 Echo 中间件层限流，因90%并发需在到达 payHandler 前拦截；用 rate.Limiter 实现中间件级限流，比在 handler 内用 if stock 判断更高效可靠。
为什么秒杀接口必须在 Echo 中间件层做限流
秒杀请求根本没资格进业务逻辑——90% 的并发在到达 payHandler 前就得被拦住。用 rate.Limiter 在中间件里卡住，比在 handler 里写 if stock 早三个执行阶段。否则光是 goroutine 创建和上下文切换就把调度器拖垮了。
常见错误现象：
• 所有请求都走通了 next(c)，但 Redis 库存瞬间归零，MySQL 订单表爆满
• echo.NewHTTPError(429) 返回的是 HTML 页面，前端无法识别
• 限流响应没带 X-RateLimit-Remaining 头，压测时没法判断是否真生效
- 限流中间件必须注册在
e.POST("/v1/pay", payHandler, RateLimitMiddleware)这种路由级位置，不能只包一层全局echo.Use() - 别在 handler 里调
limiter.Allow()：它不阻塞，但你已经花了 10ms 解析 JWT、校验参数，浪费资源 - 拒绝响应必须用
c.JSON(429, ...)或c.String(429, ...)，避免 echo 默认的 HTML 模板渲染开销
如何为每个 IP 分配独立 rate.Limiter 实例
共用一个 *rate.Limiter 就等于把所有用户关进同一个牢房：A 用户刷爆了，B 用户立刻被拒。真正的隔离靠 sync.Map + c.RealIP() 提取真实地址，不是 c.Request.RemoteAddr。
关键细节：
• c.RealIP() 自动解析 X-Forwarded-For，比手撕 header 可靠得多
• sync.Map.LoadOrStore() 返回 interface{}，必须显式断言成 *rate.Limiter
• burst 值别设成“最大并发数”，它是桶容量，比如 rate.Every(200 * time.Millisecond) 是 5 QPS，burst=10 表示允许瞬间打满 10 个
立即学习“go语言免费学习笔记（深入）”；
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 初值建议按平均 QPS × 2 设 burst（如平均 5 QPS → burst=10），上线后看
X-RateLimit-Remaining日志滚动调 - 不要用
map[string]*rate.Limiter配sync.RWMutex：读多写少场景下，sync.Map原生无锁读更高效 - IP 字符串要清洗，比如截掉端口部分：
strings.Split(c.RealIP(), ":")[0]，否则127.0.0.1:54321和127.0.0.1:54322被当成两个 IP
RateLimiter.Wait() 在 Echo 中怎么用才不超时
Wait() 会阻塞 goroutine 直到拿到令牌或 context 超时，但它在 HTTP 场景下容易翻车：默认 context 是 request context，超时时间由客户端控制（可能几秒甚至几十秒），而你真正想等的只是 100ms。
错误示范：
• 直接传 c.Request().Context() → 客户端设了 30s 超时，你的限流器就傻等 30s
• 忘记检查返回 err 类型 → context.DeadlineExceeded 和 context.Canceled 都得区分处理
- 必须用
context.WithTimeout(c.Request().Context(), 100*time.Millisecond)包一层，硬性掐断等待 - err 判断优先级：先看是否
errors.Is(err, context.DeadlineExceeded)，再看是否errors.Is(err, context.Canceled) - 别用
Wait()替代Allow()：Web 接口要快进快出，Allow()非阻塞更适合；Wait()更适合后台任务队列
多实例部署时 sync.Map 不够用怎么办
sync.Map 是单机内存结构，K8s 水平扩到 10 个 Pod 后，每个实例的限流器完全独立，A 实例放行了 100 次，B 实例又放行 100 次——总流量翻倍，防护失效。
绕不开 Redis，但别直接用 INCR + EXPIRE：竞态条件导致超卖，而且 Lua 脚本里 redis.pcall 会破坏原子性。
- 用
redis.Eval执行标准限流脚本，KEYS[1] 是"rate:ip:" + ip，ARGV[1] 是窗口秒数，ARGV[2] 是最大请求数 - 脚本必须返回明确整数：1 表示通过，0 表示拒绝，-1 表示 key 不存在（说明首次访问，需初始化）
- Go 侧拿到 1 后立刻写入本地
sync.Map缓存该 IP 的 limiter，减少后续 Redis 查询——这是本地+分布式双层兜底
真正难的是清理：sync.Map 不自动删过期 key，长期运行后内存只增不减。定时清理不如用 LRU cache（比如 github.com/hashicorp/golang-lru），设 maxEntries=10000，自动淘汰冷 key。
