@AroundInvoke注解命名疑问及Jakarta CDI拦截器执行逻辑咨询

1. 注解命名为@AroundInvoke而非@BeforeInvoke的原因 #

该注解标注的拦截方法是环绕整个目标方法的调用生命周期的，并非仅支持前置逻辑：

• 你可以在调用InvocationContext.proceed()方法前编写前置校验、参数修改等逻辑
• 可以在proceed()执行完成后编写后置结果处理、异常捕获、资源释放等逻辑
• 还可以选择不调用proceed()，直接返回自定义结果或抛出异常，完全跳过目标方法的执行
  它覆盖了前置、后置、异常处理、环绕拦截全场景，因此使用"Around"（环绕）命名而非仅指代前置逻辑的"Before"。

2. 前置访问校验的实现与执行保障 #

能否在业务API执行前调用访问校验逻辑？ #

可以，直接将访问校验逻辑编写在InvocationContext.proceed()方法调用之前即可。

什么机制保证校验逻辑在目标方法执行前完成？ #

Jakarta CDI规范明确规定了@AroundInvoke拦截器的执行是同步链式调用模型：目标方法的唯一触发入口是拦截器链最后一个节点调用proceed()方法，只有前面所有拦截器的前置逻辑全部执行完成、且依次调用了proceed()，才会最终触发目标方法运行。

是否存在VM或CDI实现会并行执行拦截器逻辑而不阻塞目标方法调用？ #

不存在。所有合规的Jakarta CDI实现都必须严格遵守规范约定的同步执行模型，并行执行拦截器的行为完全违背了拦截器的设计语义，不会被任何合规实现支持。 #

3. CDI场景下校验失败跳过目标方法的逻辑保障 #

和Google Guice AOP的行为完全一致，CDI规范强制要求：只有拦截器显式调用InvocationContext.proceed()时，才会推进拦截器链的执行、最终触发目标方法。
你只需要在校验逻辑判定失败时，直接抛出业务异常或者返回自定义响应，不调用proceed()方法，目标方法就完全不会得到执行机会，该行为是所有合规CDI实现必须支持的标准特性，不需要额外适配。 #

内容的提问来源于stack exchange，提问作者Venkata Rahul S