spring boot 全局异常处理可以通过实现 handlerexceptionresolver 接口或添加 @controlleradvice 配合 @exceptionhandler 来捕获限流触发异常。具体做法是定义一个全局异常处理器，在方法中判断异常类型是否为限流相关的类（如 sentinelblockexception 或自定义的 ratelimitexception），并返回统一的错误响应。若使用 sentinel，需确保其异常被正确抛出且未被其他过滤器吞掉；若使用 redis + lua 等自定义限流，则需在限流逻辑中主动抛出指定异常。
Sentinel 限流异常如何被全局捕获
当使用 Alibaba Sentinel 进行限流时，触发限流会抛出 SentinelBlockException。该异常默认不会自动转换为 HTTP 429 状态码，因此需要在全局异常处理器中显式捕获它。只需在 @ControllerAdvice 类中添加一个 @ExceptionHandler(SentinelBlockException.class) 方法，即可拦截该异常并返回自定义 JSON 响应。注意：Sentinel 的 Web Servlet 过滤器会自动包装部分异常，但 SentinelBlockException 仍会传播到 DispatcherServlet 的异常处理链中，因此可被 @ExceptionHandler 捕获。
import com.alibaba.csp.sentinel.slots.block.BlockException;
import com.alibaba.csp.sentinel.slots.block.authority.AuthorityRule;
import com.alibaba.csp.sentinel.slots.block.degrade.DegradeRule;
import com.alibaba.csp.sentinel.slots.block.flow.FlowRule;
import com.alibaba.csp.sentinel.slots.block.flow.param.ParamFlowRule;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.ResponseBody;
import java.util.HashMap;
import java.util.Map;
@ControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(BlockException.class)
@ResponseBody
public Map<string object> handleBlockException(BlockException e) {
Map<string object> result = new HashMap();
result.put("code", 429);
result.put("message", "请求过于频繁，请稍后重试");
result.put("type", e.getClass().getSimpleName());
return result;
}
}</string></string>
上述代码中，BlockException 是 Sentinel 所有限流、降级、授权规则的父类，捕获它能统一处理所有限流场景。测试时，可通过配置 FlowRule 限制 QPS，触发后访问任意 Controller 接口，将返回上述 JSON 结构。验证方式：启动应用后，使用 curl 高频请求受控接口，观察返回内容是否包含 code: 429 和 type: FlowException。
自定义 Redis 限流异常如何被全局捕获
若使用 Redis + Lua 脚本实现分布式限流，通常会在限流组件中手动抛出 RateLimitException。该异常需继承自 RuntimeException，以便在 Spring MVC 异常处理链中被捕获。关键点是：限流逻辑必须在 Controller 执行前或内部明确抛出异常，而不是通过返回特定状态码或静默拒绝。例如，在 AOP 切面或拦截器中检查限流条件，失败时抛出 RateLimitException，然后在 @ControllerAdvice 中用 @ExceptionHandler(RateLimitException.class) 捕获。这样可保证异常不被框架忽略，且能统一格式返回。
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.ResponseBody;
import java.util.HashMap;
import java.util.Map;
public class RateLimitException extends RuntimeException {
public RateLimitException(String message) {
super(message);
}
}
@ControllerAdvice
public class CustomRateLimitExceptionHandler {
@ExceptionHandler(RateLimitException.class)
@ResponseBody
public Map<string object> handleRateLimit(RateLimitException e) {
Map<string object> result = new HashMap();
result.put("code", 429);
result.put("message", e.getMessage());
return result;
}
}</string></string>
该方案中，RateLimitException 由限流中间件抛出，CustomRateLimitExceptionHandler 负责统一响应。测试时需确保限流逻辑确实抛出此异常，而非返回错误对象。例如，在 Spring AOP 中环绕通知内调用限流服务，若返回 false 则 throw new RateLimitException("限流")。随后发起请求，应得到包含 code: 429 和原始消息的 JSON。注意：若限流逻辑在 Filter 层完成且未转发至 DispatcherServlet，则 @ExceptionHandler 无法捕获，此时需在 Filter 中直接设置响应体或使用 RequestDispatcher 转发。
当限流异常被其他过滤器提前消费时会发生什么
如果限流逻辑部署在 Spring Filter 或 Servlet Filter 中，并在其中直接写入 HTTP 响应（如 setStatus(429) 和 writeBody），则请求不会进入 DispatcherServlet，导致 @ControllerAdvice 中的 @ExceptionHandler 无法捕获任何异常。这是因为 Filter 链在 DispatcherServlet 之前终止了请求。要解决此问题，应避免在 Filter 中直接响应，而是将限流结果通过属性传递至 Controller，或在 Filter 中抛出异常并交由 Spring 管理。另一种做法是使用 Spring 的 OncePerRequestFilter 并结合 RequestContext 标记异常，但更推荐将限流逻辑移至 AOP 或 Service 层，确保异常能进入 Spring MVC 异常处理流程。若必须使用 Filter，可考虑在 Filter 中设置一个特殊 Header 或 Attribute，由后续组件统一处理，但这会增加耦合。
