企业官网建设流程全解析

• 人工智能
• 大模型
• AI 应用
• 后端
• AI Agent
• RAG
• 流程编排
• 微服务

导读：本文基于 FIT 框架fit-aop模块的官方使用手册，系统讲解 AOP（面向切面编程）中方法拦截器（MethodInterceptor）的执行顺序问题。你将掌握：同一切面类内五类增强方法的默认优先级、不同切面同类型拦截器的未定义顺序，以及如何借助modelengine.fitframework.annotation.Order注解在类级与方法级精确控制拦截器执行次序，并了解排序背后的源码实现与测试验证，从而在实际项目中稳定编排日志、鉴权、缓存、事务等横切逻辑。

FIT 框架的 AOP 能力沉淀在 framework/fit/java/fit-aop 目录下，由三个模块组成：

• fit-aop：AOP 核心模块，提供MethodInterceptor、MethodJoinPoint、MethodMatcher、代理工厂等基础设施；
• fit-aop-aspect：基于注解的切面（@Aspect）支持，负责解析切入点表达式并生成各类拦截器；
• fit-aop-bytebuddy：基于 ByteBuddy 的 AOP 代理工厂实现。

其中，拦截器的执行顺序直接决定了多个横切逻辑叠加时的行为，是使用 FIT AOP 时必须理解的核心机制。

一、认识MethodInterceptor：AOP 中最基本的拦截单元

在 FIT 框架中，方法拦截器是处理 AOP 的最基本接口。其核心抽象定义于 MethodInterceptor.java：

public interface MethodInterceptor { @Nonnull MethodPointcut getPointCut(); @Nullable Object intercept(@Nonnull MethodJoinPoint methodJoinPoint) throws Throwable; }

每个拦截器通过getPointCut()声明自己关注的方法切点（MethodPointcut），并在intercept()中围绕方法连接点（MethodJoinPoint）执行增强逻辑。FIT 在fit-aop模块中提供了五类标准拦截器实现，全部位于 interceptor/support 目录下：

从源码可以清晰看到它们的语义差异（以 BeforeInterceptor.java 和 AfterInterceptor.java 为例）：

// BeforeInterceptor：先执行增强，再继续调用链 @Override public Object intercept(@Nonnull MethodJoinPoint methodJoinPoint) throws Throwable { this.invokeAdvisorPoint(methodJoinPoint, null, null); return methodJoinPoint.proceed(); } // AfterInterceptor：调用链结束后在 finally 中执行增强 @Override public Object intercept(@Nonnull MethodJoinPoint methodJoinPoint) throws Throwable { try { return methodJoinPoint.proceed(); } finally { this.invokeAdvisorPoint(methodJoinPoint, null, null); } }

AfterReturningInterceptor仅在proceed()成功返回后执行增强，AfterThrowingInterceptor则捕获异常并执行增强后重新抛出，AroundInterceptor直接以ProceedingJoinPoint的形式把执行权交给用户逻辑。理解这五类拦截器的语义，是理解它们之间默认执行顺序的前提。

二、同一切面类内增强类型的默认优先级

根据官方用户手册，对于被定义在同一个切面类中的增强方法，FIT 将根据增强类型分配固定优先级，从最高到最低依次为：

1. @Around
2. @Before
3. @After
4. @AfterReturning
5. @AfterThrowing

这一规则在源码中得到直接印证。MethodInterceptorComparator.java 中硬编码了类型优先级数组：

private final Class<?>[] methodInterceptorPriority = { AroundInterceptor.class, BeforeInterceptor.class, AfterInterceptor.class, AfterReturningInterceptor.class, AfterThrowingInterceptor.class };

compare()方法首先比较两个拦截器的“主顺序”（即上述类型顺序，索引越小优先级越高），仅在主顺序相同时才回退到@Order解析出的“次顺序”进行比较：

@Override public int compare(MethodInterceptor methodInterceptor1, MethodInterceptor methodInterceptor2) { int primaryOrder1 = this.getPrimaryOrder(methodInterceptor1); int primaryOrder2 = this.getPrimaryOrder(methodInterceptor2); if (primaryOrder1 == primaryOrder2) { int secondaryOrder1 = this.getSecondaryOrder(methodInterceptor1); int secondaryOrder2 = this.getSecondaryOrder(methodInterceptor2); return Integer.compare(secondaryOrder1, secondaryOrder2); } return Integer.compare(primaryOrder1, primaryOrder2); }

因此，即使@Order值相同，不同类型的拦截器依然严格按照“环绕 → 前置 → 后置 → 返回 → 抛出”的类型顺序执行，@Order只在同类型拦截器之间起决定作用。这一结论也由 MethodInterceptorComparatorTest.java 中的测试用例shouldReturnInterceptorByType验证：对同一切面类中五种类型的拦截器排序后，断言结果顺序恰为around、before、after、afterReturn、afterThrow。

三、跨切面的同类型拦截器：默认顺序未定义

当不同切面类中的同类型增强方法命中同一个连接点时，默认执行顺序是未定义的。手册给出的示例：

public class TestAspect1 { /** * 表示一个方法前置拦截器 */ public void before1() { } }

public class TestAspect2 { /** * 表示一个方法前置拦截器 */ public void before2() { } }

在默认情况下，这两个before拦截器在同一个连接点执行时，以下两种情况都合理：

1. before1()先执行，before2()后执行
2. before2()先执行，before1()后执行

之所以“未定义”，从源码结构看，是因为拦截器的收集过程（见 AspectInterceptorResolver.java）按BeanFactory遍历切面 Bean 的声明方法，而不同切面 Bean 的装载顺序并不稳定；排序阶段MethodInterceptorComparator对同类型拦截器必须依赖@Order解析出的次顺序才能给出确定结果。

但在一些特殊场景下（如多个鉴权过滤器、多级缓存、链路追踪的嵌套关系），业务上要求两者之间有严格的执行顺序。此时就必须通过设置优先级来控制执行顺序。

四、使用@Order注解控制类级优先级

FIT 提供了modelengine.fitframework.annotation.Order注解（定义于 Order.java），用于显式声明拦截器的优先级。给切面类添加@Order即可控制执行顺序：

@Order(1) public class TestAspect1 { /** * 表示一个方法前置拦截器 */ public void before1() { } }

@Order(-1) public class TestAspect2 { /** * 表示一个方法前置拦截器 */ public void before2() { } }

给定两个@Order注解，Order.value()返回值越低，优先级越高。因此上例中TestAspect2（@Order(-1)）的before2()会先于TestAspect1（@Order(1)）的before1()执行。

结合第三、四节的规则，完整的排序判定可以概括为：

1. 先比类型：@Around>@Before>@After>@AfterReturning>@AfterThrowing；
2. 再比@Order：同一类型的拦截器之间，Order.value()越小越先执行；
3. 都没有@Order时：同类型拦截器顺序未定义，落在Order.MEDIUM默认档位。

五、方法级@Order覆盖类级@Order：精细到单个增强方法

@Order注解的@Target同时包含ElementType.TYPE和ElementType.METHOD，即它可以同时标注在类和方法上。这解决了类级优先级无法覆盖“特例”的痛点。

考虑一个特殊场景：两个切面类A、B，要求A中除了前置拦截器之外的其他拦截器优先级都要高于B。

@Order(-1) public class TestAspectA { /** * 表示一个方法前置拦截器 */ @Order(2) public void before1() { } /** * 表示一个方法环绕拦截器 */ public void around1() { } }

@Order(1) public class TestAspectB { /** * 表示一个方法前置拦截器 */ public void before2() { } /** * 表示一个方法环绕拦截器 */ public void around2() { } }

解析规则为：增强方法若要通过@Order获取优先级，首先从方法自身的@Order注解获取；倘若方法上没有，则从所在类的@Order注解获取；如果两者都没有，则为@Order注解的默认值。

由此可以推导上例的最终顺序：

• TestAspectA.around1()：方法上无@Order，回落到类级@Order(-1)，优先级最高；
• TestAspectB.around2()：类级@Order(1)；
• TestAspectA.before1()：方法级@Order(2)覆盖类级@Order(-1)，成为所有前置拦截器中优先级最低者；
• TestAspectB.before2()：类级@Order(1)。

同类型的around拦截器中around1先执行；同类型的before拦截器中before2先执行。方法级注解为“类整体统一、个别方法特例”的场景提供了精确的覆盖手段。

六、@Order预定义优先级常量：语义化取值

Order注解内置了一套语义化优先级常量（见 Order.java），方便开发者直接使用而无需记忆魔法数字：

常量间的数值间距（如HIGH = -1000与NEARLY_HIGH = -100相差 900）为用户的扩展取值预留了空间，如@Order(-500)可落在HIGH与NEARLY_HIGH之间。注解的value()属性默认值为Order.MEDIUM，即0。在单元测试 MethodInterceptorComparatorTest.java 中，AdvisorClass2类上标注@Order(HIGH)、方法around2()标注@Order(LOW)，正是对这一语义化用法的直接运用。

七、源码级解析：AnnotationOrderResolver如何逐级查找@Order

类级与方法级@Order的查找逻辑由 AnnotationOrderResolver.java 实现，它实现了OrderResolver接口（见 OrderResolver.java），解析流程与手册描述完全一致：

@Override public Result resolve(MethodInterceptor methodInterceptor) { if (!(methodInterceptor instanceof AdviceMethodInterceptor)) { return Result.builder().success(false).build(); } AdviceMethodInterceptor adviceMethodInterceptor = ObjectUtils.cast(methodInterceptor); AnnotationMetadata annotations = this.resolver.resolve(adviceMethodInterceptor.getAdvisorMethod()); // 第一步：优先从增强方法上的 @Order 注解获取 if (annotations.isAnnotationPresent(Order.class)) { return Result.builder().success(true).order(annotations.getAnnotation(Order.class).value()).build(); } Object targetClass = adviceMethodInterceptor.getAdvisorTarget(); if (targetClass == null) { return Result.builder().success(false).build(); } annotations = this.resolver.resolve(targetClass.getClass()); // 第二步：方法上没有时，回退到切面类上的 @Order 注解 if (annotations.isAnnotationPresent(Order.class)) { return Result.builder().success(true).order(annotations.getAnnotation(Order.class).value()).build(); } // 第三步：都没有则解析失败，由排序器使用默认值 Order.MEDIUM return Result.builder().success(false).build(); }

结合 MethodInterceptorComparator.java 的getSecondaryOrder()可以看到：当AnnotationOrderResolver解析失败（即方法、类上均无@Order）时，排序器兜底使用Order.MEDIUM（0）作为次顺序值。此外，MethodInterceptorComparator通过 JDK SPI（ServiceLoader）加载所有OrderResolver实现，并用OrderResolver.combine(...)依次合并，意味着未来可以扩展出其他优先级解析来源（例如基于注解元数据以外的规则），当前仓库中由fit-aop-aspect模块装配该解析器并配合AspectInterceptorResolver将注解切面转化为拦截器列表。

八、测试用例印证：排序规则的完整闭环

MethodInterceptorComparatorTest.java 是fit-aop模块针对拦截器排序的单元测试，完整覆盖了本文所述的三大规则：

• AfterAddMultiInterceptors（五种类型拦截器）：断言排序结果为around1 → before1 → after1 → afterReturning1 → afterThrowing1，印证“类型优先级”规则；
• AfterAddHigherBeforeMethodInterceptorOfOtherClass：新增另一个切面中@Order(HIGH)的前置拦截器后，断言结果为around1 → before2(高优先级) → before1 → after1 → afterReturning1 → afterThrowing1，印证“同类型间@Order值越小越先执行”；
• AfterAddLowerAroundMethodInterceptorOfOtherClass：新增@Order(LOW)的环绕拦截器后，断言结果为around1 → around2(低优先级) → before1 → after1 → afterReturning1 → afterThrowing1，印证环绕拦截器内部依然先按类型整体前置、再按@Order排序。

总结与实战建议

FIT 框架的拦截器执行顺序遵循一套清晰、可预期的两级规则：

• 第一级（类型）：@Around→@Before→@After→@AfterReturning→@AfterThrowing，由 MethodInterceptorComparator 内置类型优先级保证；
• 第二级（同类型内的@Order）：优先取增强方法上的@Order，其次取切面类上的@Order，都没有则默认Order.MEDIUM，由 AnnotationOrderResolver 逐级解析。

在实际项目中，建议遵循以下实践：

1. 对同一连接点叠加多个切面时，务必显式声明@Order，不要依赖默认的未定义顺序；
2. 使用Order.HIGH/Order.LOW等语义化常量代替裸数字，提升代码可读性；
3. 方法级@Order用于特例覆盖：类级统一、个别增强方法需要调整时再下沉到方法级；
4. 善用类型优先级：例如需要“无论@Order如何，@Before都要在@After之前执行”，FIT 的类型顺序已天然保证。

通过类型优先级与@Order注解的组合，FIT 开发者可以在插件化、多切面叠加的企业级应用中，稳定、可预期地编排各类横切逻辑。

• 人工智能
• 大模型
• AI 应用
• 后端
• AI Agent
• RAG
• 流程编排
• 微服务