Spring AOP内部self调用失效是因直接通过this调用绕过代理；推荐注入代理实例（@Autowired @Lazy）或启用exposeProxy+currentProxy()；设计上应拆分职责、避免跨方法增强依赖。
这个问题本质是 Spring AOP 的代理机制限制：内部 self 调用走的是 this 引用，直接调用目标对象方法，完全绕过了代理对象，切面自然不会触发。
注入当前类的代理实例（最常用、推荐）
Spring 容器中实际管理的是代理 Bean，只要能拿到它，就能让调用走增强链：
- 在类中用 @Autowired 注入自身类型，例如 private UserService self;，Spring 默认注入的就是代理对象
- 如果启动时报循环依赖异常，加 @Lazy 即可：@Autowired @Lazy private UserService self;
- 把原代码中的 this.save(user) 改为 self.save(user)，事务、日志、缓存等注解立刻生效
启用暴露代理 + AopContext.currentProxy()（适合无法注入场景）
当类由构造器注入、或处于非 Spring 管理上下文（如 Quartz Job、@PostConstruct 中）时，注入方式不可行，可改用运行时获取：
- 全局开启暴露代理：@EnableAspectJAutoProxy(exposeProxy = true)
- 在方法内强制转型调用：((UserService) AopContext.currentProxy()).save(user)
- 注意：该调用必须发生在被 AOP 拦截过的线程中（即从代理入口进入的方法里），否则 AopContext.currentProxy() 返回 null
避免使用 ApplicationContext.getBean() 手动取代理
不推荐日常使用，仅作为特殊生命周期下的备选方案：
立即学习“Java免费学习笔记（深入）”；
- 注入 ApplicationContext，再通过 context.getBean(UserService.class) 获取代理实例
- 缺点明显：强耦合 Spring 上下文，且可能引发早期初始化问题或 Bean 创建顺序异常
- 除非万不得已（比如静态块或极早期初始化逻辑），否则优先选前两种方式
从设计层面规避（长期更健康）
频繁出现 self 调用，往往说明职责边界不清：
- 把需增强的方法拆到另一个 @Service 类中，跨 Bean 调用天然走代理
- 对通用横切逻辑（如任务记录、分布式锁、幂等校验），提取成独立组件，在需要处显式调用
- 避免在模板方法（如 BaseTask.execute()）里直接调用子类重写的方法并期望其被 AOP 拦截
