Spring AOP 和 AspectJ 有什么区别？
- 标签：后端、Spring
🏛 业务架构师
两者核心区别一句话：Spring AOP 是运行时代理（织入到容器管理的 Bean），AspectJ 是编译期/类加载期字节码织入。由此派生出能力与成本差异：
| 维度 | Spring AOP | AspectJ |
|---|---|---|
| 织入时机 | 运行时动态代理 | 编译期/加载期（ajc 编译器或 LTW） |
| 增强范围 | 只能拦截容器 Bean 的 public 方法 | 能增强任何对象，包括私有、构造器、静态、字段访问 |
| 性能 | 每次调用多一层代理开销 | 织入后无代理开销，性能最优 |
| 依赖 | 简单，Spring 自带 | 需要 ajc 编译插件或 agent，构建链复杂 |
业务选型上我的判断标准是**"够用且好治理"**：
- 事务、日志、监控埋点、权限这类方法级横切需求，Spring AOP（注解风格借用了 AspectJ 的切点表达式语法）完全覆盖，且零构建侵入——99% 的业务系统停在这里就是正确决策；
- 只有当你需要拦截字段读写、构造器、非容器对象（比如审计每个对象的创建），或者代理开销在高频热点路径上不可接受时，才值得引入 AspectJ 的织入体系；
- 引入 AspectJ 意味着构建、IDE、问题排查链路全部变复杂，团队要有明确的技术债预算。
一句话：Spring AOP 是业务系统的性价比之选，AspectJ 是特定场景的重武器，别用大炮打蚊子。
🏗 系统架构师
- 织入时机：Spring AOP 是运行时代理，只拦截 Spring Bean 的方法执行；AspectJ 是字节码织入（编译期 ajc 或加载期 LTW），能覆盖字段访问、构造器、静态方法与非容器对象；
- 能力边界：Spring 只是借用了 AspectJ 的注解语法（
@Aspect、@Pointcut），运行时并非 AspectJ 引擎在跑； - 依赖：Spring AOP 只需 spring-aop；AspectJ 需要 aspectjweaver。
我的选型判断：99% 的业务横切（事务、日志、监控）用 Spring AOP——与容器天然集成、行为可控、可调试。只有两类场景上 AspectJ：需要对第三方库代码或非容器对象织入（如追踪 JDK 内部调用、领域对象内部），或需要字段级拦截。代价是构建链复杂、对 AOT/Native 不友好、团队心智负担高。
一句话总结：Spring AOP 是「够用的工程解」，AspectJ 是「完整的语言级方案」；架构选型默认前者，确有需求才上后者。
💻 全栈开发专家
核心差异四点：
- 织入时机：Spring AOP 是运行时代理，容器启动时给 Bean 生成代理，只拦 Spring 管理的 Bean 的方法执行；AspectJ 是编译期（ajc）/类加载期（LTW）织入字节码，不依赖容器
- 能力范围：Spring AOP 只支持方法执行连接点；AspectJ 还能拦截字段读写、构造器、静态代码块
- 性能：AspectJ 织入后直接调用，无代理链开销；Spring AOP 每次调用过拦截器链
- 依赖：Spring AOP 只是借用 AspectJ 的注解和切点表达式语法（
@Aspect、execution(...)），解析和织入是自己实现的，不需要 ajc 编译器
工程选型：99% 场景（事务、日志、监控、限流）Spring AOP 足够，声明式注解即用；只有"要拦非容器对象/字段访问，或代理开销在热点路径不可接受"才上 AspectJ LTW（配 aop.xml + javaagent）。
我印象深的案例：同事想用 Spring AOP 拦截某个 DTO 的 setter 做审计，怎么配都不生效——DTO 不是容器 Bean，这种只能 AspectJ。反过来，业务 Service 方法上的横切逻辑，Spring AOP 一行注解搞定。答完差异补一句选型经验，说明真用过而不是背概念。