1. 引言
当前市面上存在多种 AOP 库，选择时需要考虑以下关键问题：
- ✅ 是否兼容现有或新应用？
- ✅ 可在哪些场景实现 AOP？
- ✅ 集成到应用的复杂度如何？
- ✅ 性能开销有多大？
本文将围绕这些问题展开，重点介绍 Java 生态中最主流的两个 AOP 框架：Spring AOP 和 AspectJ。
2. AOP 核心概念
在深入对比前，先快速回顾几个核心术语（老手可跳过）：
- 切面（Aspect）：散布在应用各处的标准代码/功能（如事务管理），通常与业务逻辑无关
- 连接点（Joinpoint）：程序执行中的特定点，如方法调用、构造器执行或字段赋值
- 通知（Advice）：切面在特定连接点执行的动作
- 切入点（Pointcut）：匹配连接点的表达式，当连接点匹配时执行关联通知
- 织入（Weaving）：将切面与目标对象链接创建代理对象的过程
3. Spring AOP 与 AspectJ 深度对比
从能力、目标、织入方式、内部结构、连接点支持和易用性六个维度展开分析：
3.1. 能力与目标差异
两者设计目标截然不同：
- Spring AOP：专注于为 Spring IoC 提供轻量级 AOP 实现，解决开发者最常见痛点。⚠️ 注意：它不是完整 AOP 解决方案，仅能作用于 Spring 容器管理的 Bean
- AspectJ：作为原始 AOP 技术，旨在提供完整 AOP 解决方案。功能更强大但也更复杂，可应用于所有领域对象
3.2. 织入机制对比
织入方式直接影响性能和易用性：
AspectJ 支持三种织入方式：
- 编译期织入：AspectJ 编译器同时处理切面源码和业务代码，直接生成织入后的 class 文件
- 后编译织入：又称二进制织入，对现有 class 文件和 JAR 包进行织入
- 加载期织入：类似二进制织入，但推迟到类加载器将 class 文件加载到 JVM 时执行
关于 AspectJ 的更多细节可参考 这篇深度文章
Spring AOP 仅支持运行时织入： 在应用运行时通过目标对象的代理（JDK 动态代理或 CGLIB 代理）织入切面：
3.3. 内部结构与实现原理
Spring AOP 基于代理模式： 通过创建目标对象的代理实现切面，有两种代理方式：
- JDK 动态代理（优先选择）：当目标对象实现至少一个接口时使用
- CGLIB 代理：目标对象未实现接口时使用
深入了解代理机制可参考 Spring 官方文档
AspectJ 的实现完全不同：
在编译阶段直接将切面织入字节码，运行时零额外操作。无需设计模式支持，通过专属编译器 ajc 编译代码，运行时仅需一个轻量级库（<100K）。
3.4. 连接点支持范围
Spring AOP 的代理机制带来明显限制：
- ❌ 无法作用于 final 类：因为不能被继承，会导致运行时异常
- ❌ 不支持 static/final 方法：同样因为无法被重写
- ✅ 仅支持方法执行连接点
AspectJ 则直接修改字节码，支持更丰富的连接点：
| 连接点类型 | Spring AOP | AspectJ |
|---|---|---|
| 方法调用 | ❌ | ✅ |
| 方法执行 | ✅ | ✅ |
| 构造器调用 | ❌ | ✅ |
| 构造器执行 | ❌ | ✅ |
| 静态初始化 | ❌ | ✅ |
| 对象初始化 | ❌ | ✅ |
| 字段引用 | ❌ | ✅ |
| 字段赋值 | ❌ | ✅ |
| 异常处理 | ❌ | ✅ |
| 通知执行 | ❌ | ✅ |
⚠️ 踩坑提示：Spring AOP 中切面不会作用于同类内部方法调用（因为调用的是原始对象而非代理）。如需此功能，需拆分到不同 Bean 或改用 AspectJ。
3.5. 易用性对比
Spring AOP 明显更简单：
- 无需额外编译器或织入器
- 与现有构建流程无缝集成
- ⚠️ 限制：仅适用于 Spring 管理的 Bean
AspectJ 集成更复杂：
- 需引入 AspectJ 编译器（ajc）
- 除非使用后编译/加载期织入，否则需重新打包所有库
- 需集成 AspectJ 工具链（编译器 ajc、调试器 ajdb 等）到 IDE 或构建工具
3.6. 性能表现
编译期织入显著优于运行时织入：
- Spring AOP：启动时创建代理对象，每次切面执行增加额外方法调用，性能开销较大
- AspectJ：应用执行前完成织入，运行时零开销
基准测试 显示：AspectJ 比 Spring AOP 快 8-35 倍。
4. 核心差异总结
| 对比维度 | Spring AOP | AspectJ |
|---|---|---|
| 实现方式 | 纯 Java 实现 | Java 语言扩展实现 |
| 编译过程 | 无需单独编译 | 需 ajc 编译器（除非使用 LTW） |
| 织入时机 | 仅运行时织入 | 支持编译期/后编译期/加载期织入 |
| 能力范围 | 较弱（仅方法级织入） | 强大（字段/方法/构造器等全面支持） |
| 适用对象 | 仅 Spring 容器管理的 Bean | 所有领域对象 |
| 切入点支持 | 仅方法执行 | 全部类型 |
| 实现原理 | 创建目标对象代理 | 运行前直接织入代码 |
| 性能 | 较慢 | 高性能 |
| 学习成本 | 简单易学 | 相对复杂 |
5. 如何选择合适框架
没有绝对优劣，选择取决于具体需求：
5.1. 框架依赖
- ✅ Spring 全栈应用：优先选 Spring AOP，学习成本低且集成简单
- ❌ 非 Spring 应用：必须用 AspectJ（Spring AOP 无法管理容器外对象）
5.2. 功能需求
- ✅ 常规切面需求（如日志/事务）：Spring AOP 足够
- ✅ 复杂切面需求（如字段修改/构造器拦截）：必须用 AspectJ
5.3. 性能要求
- ✅ 少量切面（<100）：两者差异可忽略
- ❌ 海量切面（>10,000）：必须用 AspectJ（性能差异可达 35 倍）
5.4. 混合使用策略
两者完全兼容，可组合使用：
// 优先使用 Spring AOP 处理常规需求
@Aspect
@Component
public class LoggingAspect {
// Spring AOP 实现
}
// 特殊场景用 AspectJ 补充
@Aspect
public class FieldAccessAspect {
// AspectJ 实现字段拦截
}
6. 结论
本文从灵活性、集成难度、性能等关键维度对比了 Spring AOP 和 AspectJ：
- Spring AOP：适合 Spring 生态中的常规切面需求，简单易用但能力有限
- AspectJ：企业级 AOP 解决方案，功能强大但集成复杂，性能优势明显
实际开发中，建议根据项目需求灵活选择，必要时可组合使用两者优势。