Spring AOP内部调用失效本质是self调用绕过代理，解决关键是让调用走代理链：推荐注入代理实例（@Autowired @Lazy）、次选暴露代理+AopContext.currentProxy()、慎用getBean()、最优是设计重构规避。
这个问题本质是 Spring AOP 代理机制的天然限制：内部 self 调用绕过了代理对象，切面逻辑根本没机会执行。解决的关键不是“绕开 AOP”，而是让调用真正走代理链。
注入当前类的代理实例（最常用、推荐）
Spring 容器中实际管理的是代理对象，只要能拿到它，就能触发增强逻辑：
- 在类中用 @Autowired 注入自身类型（如
private UserService self;），Spring 默认注入的就是代理 Bean - 若启动时报循环依赖异常，加 @Lazy 延迟加载即可：
@Autowired @Lazy private UserService self; - 调用时改
this.save(user)为self.save(user)，事务、日志、缓存等注解立刻生效
启用暴露代理 + AopContext.currentProxy()（适合无法注入场景）
当类被构造器注入、或处于非 Spring 管理上下文（如 Quartz Job）时，注入方式不可用，可改用运行时获取：
- 全局开启暴露代理：
@EnableAspectJAutoProxy(exposeProxy = true) - 在方法内强制转型调用：
((UserService) AopContext.currentProxy()).save(user) - 注意：必须确保当前线程是 Spring AOP 拦截过的（即从代理入口进来的），否则
currentProxy()返回 null
用 ApplicationContext.getBean() 手动取代理（慎用）
不推荐日常使用，但在某些特殊生命周期（如 @PostConstruct）中可作为备选：
- 注入
ApplicationContext，再通过context.getBean(UserService.class)获取代理实例 - 缺点是强耦合 Spring 上下文，且可能引发早期初始化问题，优先考虑前两种方案
设计层面规避（一劳永逸）
如果一个类频繁出现 self 调用，说明职责可能过重，重构往往比硬套代理更健康：
- 把需增强的方法拆到另一个
@Service类中，跨 Bean 调用天然走代理 - 对通用横切逻辑（如任务记录、锁控制），提取成独立组件，在需要处显式调用，而非依赖注解自动织入
- 避免在模板方法（如
BaseTask.execute()）里直接调用子类重写的方法并期望其被 AOP 拦截
