grep -rn 'addFilterBefore\|Ordered' src/main/java/**/FilterConfig.java curl -s 'localhost:8081/actuator/metrics/http.server.requests?tag=status:429' | jq '.measurements'
大促峰值 QPS 3.2 万，配置里限流阈值 8000，实际到应用层的请求还是 3.2 万。降级逻辑里的本地缓存查了 3.2 万次，CPU 打到 95%，接口耗时反而比不限流时更高。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：过滤器链里降级排在限流前面，请求先走完降级分支才被限流拦下，等于降级承担了全部流量。限流阈值按通过量算，没算上被降级提前消费的那部分。
这次卡住的地方就在「限流降级顺序」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
处理上按这个顺序：把限流过滤器提到降级之前 保证只有放行的请求才进业务逻辑；确认过滤器 order 值 限流要比降级小；限流拒绝的请求直接返回 429 不进降级分支；压测对比调整前后 CPU 和 P99。
确认没问题再收工，峰值时应用层 QPS 稳定在 8000，429 占比符合预期，CPU 不超过 60%，P99 回落到 200 毫秒内。