应单独定义ratelimitexception类处理限流降级异常，全局拦截返回429状态码及标准响应体，warn日志记录规则标识，前端配合倒计时提示与静默降级，监控中独立统计429指标。
接口限流降级异常需单独归类处理
限流降级（如 Sentinel、Resilience4j 或自研限流器触发）产生的异常，本质属于“系统保护行为”，不是业务错误或系统缺陷。它应与 BusinessException、ValidationException 等明确区分，避免被泛化捕获为 500 错误。否则前端无法识别“服务繁忙，请稍后再试”这类友好提示，也难以做重试或降级 UI 展示。
定义专用限流异常类型
统一使用一个继承 RuntimeException 的限流异常类，确保所有限流组件抛出的异常都能被精准识别：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 推荐命名为 RateLimitException 或 FlowControlException
- 包含字段：code（如 429）、message（如 “请求过于频繁，请稍后重试”）、可选 traceId（用于链路追踪）
- 若集成 Sentinel，可通过
BlockExceptionHandler将 BlockException 包装成该自定义异常；若用 Resilience4j，可在 CircuitBreaker 或 RateLimiter 的 fallback 中主动 throw
在全局异常处理器中专案响应
使用 @RestControllerAdvice 拦截该异常，并返回标准结构 + 明确 HTTP 状态码：
- 匹配注解：
@ExceptionHandler(RateLimitException.class) - 返回状态码建议设为 429 Too Many Requests（符合 RFC 7231），而非 400 或 500
- 响应体复用项目统一的
Result>或ApiResponse>，例如：return Result.fail(429, "当前请求频率过高，请稍后再试"); - 记录日志时使用 WARN 级别，并带上限流规则标识（如 resource="order/create"、ruleType="QPS"），不打 ERROR 堆栈（因非故障）
配合前端做体验优化
仅后端拦截不够，需前后端协同提升用户体验：
- 前端收到 429 响应后，自动禁用提交按钮并显示倒计时（如“请 15 秒后重试”）
- 对非关键接口（如点赞、浏览统计），可配置静默降级：捕获
RateLimitException后返回Result.success(null)，不报错也不提示 - 监控告警层面，将 429 响应数纳入 QPS 异常波动指标，而非混入“错误率”大盘
