将@ControllerAdvice用在静态内部类上是否属于不良实践？

我在应用中需要两个标注@ControllerAdvice的类：一个处理特定异常（优先级最高），另一个作为默认处理器处理所有未预期异常（优先级更低）。两者需要共享从异常构建ResponseEntity的自定义逻辑，于是我把这两个类作为静态内部类放到一个外部类中，代码示例如下：

public class ExceptionHandler {

  private static ResponseEntity handleError(Exception ex, String message){ 
    // 共享的异常处理逻辑
  }
  
  @ControllerAdvice
  @Order(Ordered.HIGHEST_PRECEDENCE)
  static class SpecializedExceptionHandler {
    
    @ExceptionHandler
    ResponseEntity handleMyException(MyException ex){
      return handleError(ex, "Custom Exception");
    }
  }

  @ControllerAdvice
  static class DefaultExceptionHandler {
    
    @ExceptionHandler
    ResponseEntity handleAllOtherExceptions(Exception ex){
      return handleError(ex, "Other Exception");
    }
  }
}

目前该方案运行正常，但我无法自行找出其弊端，希望得到解答。

• 违背单一职责原则：外部类ExceptionHandler既充当了多个异常处理器的容器，又承载了共享的异常处理逻辑，一个类承担两种不同职责。后续新增异常处理器时，类的复杂度会快速上升，维护难度变大。
• 可扩展性不足：如果后续需要新增其他优先级的异常处理器（比如中等优先级的业务异常处理器），只能继续在这个外部类中添加静态内部类，最终会导致外部类臃肿不堪，成为难以维护的“大泥球”。
• 命名冲突风险：外部类命名为ExceptionHandler，和Spring核心注解@ExceptionHandler同名，代码编写、阅读时容易造成混淆，IDE自动提示也可能出现干扰，增加团队成员的理解成本。
• 测试灵活性差：共享逻辑是外部类的私有静态方法，若后续需要对这部分逻辑做单元测试（比如Mock特定场景），静态方法的测试和替换会比独立工具类麻烦很多；换成独立的Spring Bean或工具类，测试灵活性会更高。
• 依赖注入受限：当前共享逻辑是静态方法，若后续需要依赖Spring容器中的Bean（比如日志组件、配置服务），静态方法无法直接通过@Autowired注入依赖，只能通过静态字段或手动获取Spring上下文解决，这会引入紧耦合，不符合Spring依赖注入的设计理念。

内容的提问来源于stack exchange，提问作者duriz