原理（下）：AOP 代理的生成与失效

3.1自动代理创建器：02 章那个"最后一步的 BPP"

Spring 不会凭空给 bean 加代理。干这件事的是一个具体的组件——AnnotationAwareAspectJAutoProxyCreator，它本身就是一个 BeanPostProcessor。它在每个 bean 走到生命周期第 ③d 步（postProcessAfterInitialization）时被回调，检查这个 bean 是否命中了某个切面的切点；命中就返回一个代理，没命中就原样返回。把图 2.2 的第 ③d 步放大，就是这张图：

3.2代理怎么造：JDK 动态代理 vs CGLIB

JDK 动态代理给"有接口的目标"造一个实现同接口的代理；CGLIB 给"没接口的目标"造一个继承它的子类。

底层机制（比文档深一层）：JDK 动态代理在运行期用 java.lang.reflect.Proxy 生成一个实现了目标接口的类，方法调用统一进入 InvocationHandler.invoke，由它决定"先跑通知、再转发给目标"。CGLIB 则用字节码生成一个目标类的子类，覆盖每个非 final 方法插入增强。选择规则：Spring Framework 默认"有接口走 JDK、没接口走 CGLIB"；但 Spring Boot 自 2.0 起默认强制 CGLIB（proxyTargetClass=true），因为按接口代理时，注入点若写成实现类而非接口会注入失败，统一用 CGLIB 更稳。

3.3自调用失效：最经典的"事务没生效"

增强只在"从外部经过代理引用"的调用上触发；对象内部 this.method() 走原始引用，绕过代理，通知不触发。

01 章表 1.1 的加粗结论，在这里兑现。代理增强的前提是"调用先经过代理对象"。一个 bean 的方法 A 里直接调用本类的方法 B（this.methodB()），这个调用走的是原始对象的引用（this 永远指向原始目标，不是代理），根本没经过代理那一层，于是 B 上的 @Transactional / @Async / @Cacheable 通知统统不触发。

@Service
public class OrderService {

    public void placeOrder(Order o) {
        // 从外部被调用：placeOrder 经过代理 —— 但它自己没有 @Transactional
        this.saveWithTx(o);   // ← this 调用：直达原始对象，绕过代理
    }

    @Transactional
    public void saveWithTx(Order o) {
        // 期望这里开启事务；可经 this 调进来时，事务通知不触发，事务不存在
    }
}

三种修法（都在"让调用重新经过代理"上做文章）：把 saveWithTx 拆到另一个 bean 去调用；让 bean 自己注入自己（注入的是代理），用 self.saveWithTx(o)；或用 AopContext.currentProxy() 取当前代理再调。本质都是绕开 this。

同一根因的一串失败模式

"自调用绕过代理"不是孤例，它是一整族失败模式的共同根因。把它们摆在一起，根因一眼看穿：

这张表把前三章串成一条因果链——表里每个"根因"都指回某一节的机制。这正是把 Spring 当状态机看的回报：失败模式不用背，从机制能推出来。

3.4@Configuration 自己也是代理：full vs lite

@Configuration 类被 CGLIB 增强，使其 @Bean 方法之间互相调用时仍返回容器里的同一个单例。

一个常被忽略的事实：@Configuration 类自己也会被 CGLIB 代理。原因是 @Bean 方法之间会互相调用——如果不拦截，一个 @Bean 方法里调用另一个 @Bean 方法，就是一次普通 Java 方法调用，会再造一个新对象，破坏单例。

@Configuration                  // full 模式：类被 CGLIB 增强
public class AppConfig {
    @Bean public PaymentGateway gateway() { return new StripeGateway(repo()); }
    @Bean public InventoryRepository repo() { return new MySqlInventoryRepository(); }
    // gateway() 里调用 repo()：被代理拦截，返回容器里那个单例 repo，不是新对象
}

3.5判别：Spring AOP 还是 AspectJ？

Spring 代理式 AOP 的所有限制（只能方法、只对 bean、自调用失效），都源于"运行期靠代理织入"这一个选择。完整的 AspectJ 走另一条路——编译期或类加载期直接改字节码织入，因此没有这些限制。这是本章的判别点。

判别准则：默认用 Spring AOP——日志、事务、缓存这类"作用在 bean 的公开方法上"的横切，它完全够用且零成本。只有当需求落在它的盲区——要拦字段读写或构造器、要增强非 bean 的普通对象、要让自调用也生效——才升级到 AspectJ，接受它的额外工具链成本。能用代理解决就别上字节码织入。