AOP 失效的 7 种死法与复活指南

还是那句话知识是一个返回的过程追一句时间出真知今天我们要聊的是一个“灵异事件”频发的领域——Spring AOP 失效。你是不是也经历过这种崩溃“明明加了Transactional为什么数据库报错不回滚”“明明加了Log为什么控制台静悄悄”“明明加了Async为什么还是串行执行”于是你开始怀疑人生怀疑 Spring 源码有 Bug。停别甩锅给 Spring。真相往往很残酷AOP 没死是你“用法”错了。AOP 失效的本质用一句话概括就是“电话打错了人”。你想找“代理人”Proxy办事加事务、加日志结果你直接绕过了前台冲进了办公室找到了“本人”Target。“本人”当然不会干那些杂活日志、事务他只会闷头干业务。今天我们就从底层原理出发盘点 AOP 的7 种死法并手把手教你复活术。死法一同类内部自调用The Self-Invocation Suicide死亡率最高90% 的新手都死在这场景描述你在UserService里写了一个public方法 A里面调用了同一个类里的Transactional方法 B。结果事务失效。原理Spring AOP 是基于代理的。当你注入UserService时你拿到的是UserServiceProxy。当你调用userService.methodA()时走的是 Proxy - A -this.methodB()。注意这个this在类内部this指向的是原始对象Target而不是代理对象Proxy。所以调用直接跳过了 Proxy 的拦截逻辑直捣黄龙。复活指南方案 A自注入推荐 有时候会有问题Service public class UserService { Autowired Lazy // 必须加 Lazy防止循环依赖报错 private UserService self; public void methodA() { self.methodB(); // 通过代理对象调用 } // ... }方案 BAopContext黑科技// 需配置 EnableAspectJAutoProxy(exposeProxy true) public void methodA() { ((UserService) AopContext.currentProxy()).methodB(); // 获取当前代理 }死法二非 Public 方法的“隐身术”死亡率场景描述你想隐藏业务逻辑把Transactional方法设为protected或private。结果事务失效。Service public class UserService { Transactional protected void methodB() { // 死亡瞬间 // 数据库操作 } }原理JDK 动态代理只能代理接口的方法默认public。CGLIB虽然能代理非 public 方法但 SpringAOP的切点匹配规则Pointcut默认只匹配public方法。更重要的是代理对象子类无法直接访问父类的private方法。边界感很重要滴复活指南老老实实把方法设为public。如果非要隐藏逻辑请将非 public 方法提取到另一个 Service 中通过注入调用。死法三New 出来的对象是“孤儿”死亡率场景描述你在Controller或者main方法里直接new UserService()。结果AOP 完全失效。RestController public class UserController { public void createUser() { UserService service new UserService(); // 死亡瞬间 service.methodB(); } }原理Spring AOP 的核心是Spring 容器IOC。只有被 Spring 容器管理的 BeanSpring 才能在启动时给它生成代理对象。你自己new出来的对象是游离于容器之外的孤儿Spring 根本不知道它的存在更别提给它穿马甲了。Autowired private UserService userService; // 注入的是代理对象死法四异常被 Try-Catch 吃掉了死亡率隐蔽性极高场景描述你在Transactional方法里自己捕获了异常。结果报错了但事务提交了没回滚。Transactional public void methodB() { try { // 数据库操作 int i 1 / 0; } catch (Exception e) { e.printStackTrace(); // 死亡瞬间 // 异常被吞了方法正常返回 } }原理Spring 事务拦截器TransactionInterceptor的逻辑是捕获到 RuntimeException 才回滚。如果你在方法内部把异常catch住了并且没有重新抛出throw e拦截器会觉得“咦方法正常执行结束了那我提交事务吧。”Transactional public void methodB() { try { // ... } catch (Exception e) { log.error(error, e); throw new RuntimeException(e); // 必须抛出来 } }死法五Final 方法/类的“封印”死亡率场景描述你为了代码规范把 Service 类或方法加上了final修饰符。结果AOP 失效。Service public class UserService { Transactional public final void methodB() { // 死亡瞬间 // ... } }Spring AOP 默认使用 CGLIB基于继承。Java 语法规定final方法/类 不能被继承/重写。CGLIB 生成的子类无法重写final方法也就无法插入拦截逻辑。调用直接穿透到父类原始方法去掉final。Spring Bean 默认就是单例且可变的不需要final。如果非要不可变考虑使用 AspectJ编译时织入。死法六数据库引擎不支持MyISAM 陷阱死亡率虽然少见但坑死人场景描述你代码写对了注解加对了异常也抛了。结果数据库还是没回滚。原理Transactional只是告诉 Spring“我要开启事务”。Spring 会向数据库发送BEGIN指令。但是如果你的数据库表引擎是MyISAM老旧引擎它根本不支持事务数据库直接忽略事务指令执行完就完事了。检查数据库表引擎。确保你的表是InnoDB引擎。SHOW CREATE TABLE your_table_name;死法七切面优先级错乱死亡率场景描述你有多个切面比如日志切面、事务切面、权限切面。结果执行顺序乱了导致逻辑错误比如日志没记录到异常信息。原理Spring AOP 是基于拦截器链的。如果多个切面匹配同一个方法执行顺序取决于Order或Priority。默认情况下顺序是不确定的或者说按 Bean 名称排序这会导致生产环境和测试环境表现不一致。Aspect Order(1) // 数字越小优先级越高越靠近方法调用入口 public class LogAspect { ... } Aspect Order(2) public class TransactionAspect { ... }“五步捉鬼法”第一步确认“鬼”是否存在 —— 检查代理对象AOP 生效的前提是你拿到的对象必须是代理对象Proxy而不是原始对象Target。这是所有排查的起点。操作在你的代码里比如 Controller 或PostConstruct方法中打印出这个 Bean 的 Class 类型 System.out.println(Bean 的真实身份是: myService.getClass());结果分析情况 Aclass com.example.MyService$$EnhancerBySpringCGLIB$$...结论鬼魂已现形这是 CGLIB 生成的代理子类。AOP 的基础是好的问题可能出在后续步骤。情况 Bclass com.sun.proxy.$ProxyXX结论鬼魂已现形这是 JDK 动态代理的产物。基础也是好的。情况 Cclass com.example.MyService结论见鬼了你拿到的是原始对象根本没有代理AOP 当然不会生效如果结果是 C请直接跳转到【复活指南 1】。第二步检查“咒语”是否念对 —— 审查切点表达式代理对象有了但它的“魔法”没触发。这通常是因为你的“咒语”切点表达式Pointcut写错了没能精准匹配到目标方法。常见错误包路径错误execution(* com.example.service.*.*(..))只能匹配service包下的类如果类在service.impl下就失效了。应该用..表示子包。方法名错误execution(* *save*(..))只能匹配包含 save 的方法createUser就匹配不上。注解错误annotation(MyAnnotation)写成了annotation(com.example.MyAnnotation)(全限定名在某些版本可能有问题)。操作要认真仔细检查你的Pointcut表达式或者使用 IDE 的 AspectJ 表达式检查工具如果支持来验证。如果怀疑是这里的问题请直接跳转到【复活指南 2】。第三步检查“电话”是否打给了“鬼” —— 排查调用方式这是最高频的失效原因你拿到了代理对象也写对了切点但 AOP 还是不工作。核心原因自调用Self-Invocation。你正在和“本人”原始对象通话而不是“代理人”代理对象。代理人自然无法插手。典型场景在同一个类中一个普通方法methodA调用了带 AOP 注解的方法methodB。Service public class UserService { public void methodA() { this.methodB(); // ❌ 这里的 this 是原始对象 } Transactional public void methodB() { ... } }操作检查你的调用链路。如果是类内部调用那基本就是这个问题。如果遇到这个问题请直接跳转到【复活指南 3】。第四步检查“鬼魂”的“体质” —— 审查方法与类的修饰符有些“鬼魂”天生有缺陷无法施展法力。这通常和方法的修饰符有关。常见限制final方法/类CGLIB 代理基于继承final方法无法被重写因此无法被拦截。private/protected方法代理对象子类无法访问父类的私有方法Spring AOP 默认也只拦截public方法。static方法静态方法属于类不属于对象实例动态代理无法拦截。操作检查你的目标方法是否被这些修饰符“封印”了。如果遇到这个问题请直接跳转到【复活指南 4】。第五步检查“房子”是否归“鬼”管 —— 确认 Bean 管理权这是最根本的问题。如果一个对象根本不在 Spring 容器里Spring 怎么可能为它创建代理呢常见错误使用new UserService()手动创建对象。类上忘记加Component,Service,Controller等注解。包扫描路径ComponentScan没有覆盖到这个类。操作确认你的目标类是被Autowired注入进来的而不是自己new出来的。如果遇到这个问题请直接跳转到【复活指南 5】。AOP 失效复活指南复活指南 1让 Spring 接管对象错误UserService service new UserService();正确Autowired private UserService service;确保类上有Service等注解且在扫描路径内。复活指南 2修正“咒语”错误execution(* com.example.service.*.*(..))正确execution(* com.example.service..*.*(..))(注意..代表当前包和所有子包)。复活指南 3确保调用的是代理Service public class UserService { Autowired Lazy private UserService self; // 注入代理对象 public void methodA() { self.methodB(); } // 通过代理调用 }((UserService) AopContext.currentProxy()).methodB(); // 需配置 exposeProxytrue方案 C (最佳实践)重构代码将methodB移到另一个 Service 中。复活指南 4解除修饰符“封印”操作去掉final、static修饰符将private/protected方法改为public。复活指南 5处理特殊冲突场景引入 Shiro 等框架后AOP 突然失效。原因多个框架都试图创建代理导致冲突。操作统一代理策略。在启动类或配置类上强制使用 CGLIB。SpringBootApplication EnableAspectJAutoProxy(proxyTargetClass true) // 强制 CGLIB public class MyApplication { ... }总结程序员避坑心法AOP 失效归根结底是因为代理对象Proxy的存在感被削弱了死法根本原因复活口诀自调用this指向原始对象自注入用代理非 Public代理无法访问/匹配公开方法最安全New 对象对象不在容器内注入别用 New吃掉异常拦截器收不到信号异常必须抛FinalCGLIB 无法继承Final 是禁区MyISAM数据库不支持引擎要 InnoDB优先级拦截器链顺序乱Order 显式排“AOP 失效通常不是因为框架 bug而是因为开发者误以为自己在和代理对象交互实际上却直接操作了目标对象。理解‘代理对象’的存在感是避坑的关键。”