AOP（Aspect-Oriented Programming，面向切面编程）解决的是一类“横切关注点”问题。

这些逻辑不属于任何一个核心业务用例，却几乎散落在所有用例周围，例如日志、权限、事务、监控、幂等等。

把它们从业务代码里抽离出来，集中声明、统一织入（weaving），业务代码就能保持干净、稳定，治理策略也更可控。

AOP 的典型应用场景（按工程收益排序）

1）统一日志与审计（Audit）

• 访问日志：记录接口入参、出参、耗时、调用方标识、traceId（链路标识）。
• 审计日志：记录“谁在什么时间对什么资源做了什么操作”，通常要求不可抵赖、可追溯。
• 价值：避免在每个 Service/Controller 里手写 log.info()；字段口径一致，便于检索与风控。

典型切点：

• Controller 层：记录 HTTP 请求维度信息（URI、method、IP、UA）。
• Service 层：记录业务动作（下单、退款、审批）与关键业务 ID。

2）鉴权、登录态与数据权限

• 接口鉴权：基于角色/权限点/资源范围的拦截。
• 数据权限：例如同一接口返回数据需按部门、租户、组织树过滤。
• 价值：避免权限判断散落在各处导致遗漏；策略可集中升级（例如从 RBAC 升级到 ABAC）。

注意边界：

• 粗粒度鉴权常在网关或过滤器做；细粒度（到方法/资源）更适合 AOP。

3）事务管理与一致性边界

• 典型：Spring @Transactional 本质就是 AOP 代理在方法边界开启/提交/回滚事务。
• 价值：将数据库事务与业务方法边界绑定，避免手写 begin/commit/rollback。

常见陷阱（影响实际效果）：

• 同类内部方法调用（self-invocation）绕过代理导致事务不生效。
• 异步/新线程内执行不继承事务上下文。
• 仅对 public 方法生效（常见默认代理策略下）。

4）性能监控与链路追踪（Metrics/Tracing）

• 耗时埋点：方法级耗时、异常率、慢调用统计。
• Tracing：在入口生成或透传 traceId/spanId，打通日志、指标与调用链。
• 价值：性能治理落到方法粒度；定位“慢在哪里”比“慢了”更重要。

5）异常治理与统一错误码

• 异常转换：将底层异常（SQL、RPC、网络）统一转换为领域错误码与可读信息。
• 降噪：对可预期异常降级日志级别，对未知异常保留堆栈与告警。
• 价值：错误口径统一，前端/调用方契约稳定。

说明：Web 层的统一异常处理常由 @ControllerAdvice 完成；AOP 更适合 Service/RPC 方法边界的异常策略。

6）幂等、限流、熔断与重试（Resilience）

• 幂等：重复请求只生效一次（支付回调、消息消费、创建类接口）。
• 限流/熔断/重试：围绕外部依赖（RPC、第三方 API）的稳定性策略。
• 价值：与业务解耦，策略可配置、可迭代。

实现方式：

• AOP + Redis（幂等 key、分布式锁、令牌桶计数）。
• AOP + Resilience4j/Sentinel（限流熔断）更常见。

7）参数校验与契约约束

• 对方法入参做统一校验（非空、范围、格式、跨字段约束）。
• 价值：减少重复 if 判断；失败策略统一（错误码、提示语、日志级别）。

补充：Java 常用 Bean Validation（JSR 380）在 Controller/Service 也可通过 AOP 触发与增强。

8）缓存（Cache Aside）与防穿透

• 读取前先查缓存，失效再回源；写入后失效缓存。
• 价值：将缓存策略从业务代码剥离，避免“到处写缓存”导致一致性混乱。

注意：缓存与业务一致性强相关，AOP 更适合“可容忍短暂不一致”的读多写少场景；强一致要更谨慎。

在项目中应用 AOP 的落地方式（从设计到上线）

1）先定“切面边界”：在哪一层织入

常用选择：

• Controller 边界：更贴近请求语义，适合访问日志、traceId、统一入参脱敏、灰度标记读取。
• Service 边界：更贴近业务动作，适合事务、权限点校验、幂等、审计、指标。
• Client/RPC 边界：更贴近外部依赖，适合重试、熔断、超时、降级、调用统计。

边界选择原则：

• 和“责任归属”对齐：谁拥有这个策略的变更权。
• 和“失败后果”对齐：例如幂等应尽量靠近写入点（Service/Repo）。

2）用注解表达意图，用 Pointcut 表达范围

落地基本套路是“自定义注解 + 切点表达式”：

• 注解表达业务意图：@Audit、@Idempotent、@RateLimit。
• Pointcut 表达作用范围：包路径、类/方法、注解、参数类型。

示例（概念级）：

• @Pointcut("@annotation(com.xxx.Audit)")
• @Around("execution(* com.xxx..service..*(..)) && @annotation(audit)")

这样做的好处是范围可控，避免“一刀切”拦截导致性能与副作用问题。

3）选对 Advice 类型：Around/Before/AfterThrowing

• @Around：最常用，可拿到入参、执行目标方法、拿到返回值、捕获异常、统计耗时。
• @Before：做前置校验、上下文准备（traceId、租户信息）。
• @AfterReturning：对返回结果做审计、埋点补充。
• @AfterThrowing：对异常做分类处理、告警、错误码映射。

工程上常见组合：

• 监控与耗时：@Around
• 权限：@Before 或 @Around
• 异常治理：@AfterThrowing 或 @Around

4）把“横切逻辑”做成可配置组件，而不是硬编码

可配置点通常包括：

• 日志采样率、脱敏字段列表、最大入参长度
• 幂等 key 的生成策略（用户维度、业务单号维度、请求体 hash）
• 限流阈值、时间窗口、白名单
• 重试次数、退避策略（指数退避）、只重试的异常类型集合

配置来源：

• Spring @ConfigurationProperties
• 配置中心（Nacos/Apollo 等）
• 运行时动态开关（灰度）

5）处理好顺序与嵌套：@Order 与事务/重试/幂等的关系

多个切面叠加时，“谁包住谁”会改变语义：

• 幂等通常要在最外层：先拦重复请求，再执行业务。
• 事务要包住写入：但不要被“重试”无脑包住，否则可能造成重复写。
• 重试更适合包住“外部依赖调用”，而不是整个业务方法。

在 Spring 中常用：

• @Order 或实现 Ordered 控制切面优先级（数值越小优先级越高）。

6）避免 AOP 的常见坑（影响生产效果）

• 代理失效：同类内部调用绕过代理；解决方式包括拆分 Bean、通过代理调用、或使用 AspectJ 编织。
• 切点过宽：拦截范围太大引起性能问题或误拦截（例如把 getter/setter 也拦了）。
• 拿不到参数名：需要编译参数 -parameters 或借助调试信息；否则审计字段提取困难。
• 线程上下文丢失：traceId、租户信息在异步场景需显式传递（TTL、MDC 复制等）。
• 异常吞掉：切面捕获异常后未再抛出，导致上层误以为成功，必须严格规定异常传播策略。
• 返回值包装污染：切面统一包装响应时要考虑接口契约与序列化兼容，通常放在 Web 层更稳。

7）一套可复用的“项目级 AOP 套件”长什么样

常见的可落地组合：

• AuditAspect：注解驱动，抽取业务 ID、操作者、动作类型，写审计表或消息。
• MetricAspect：方法级耗时与异常率，打点到 Prometheus/Micrometer。
• IdempotentAspect：基于 Redis 的幂等 key + TTL + 并发互斥策略。
• PermissionAspect：权限点校验 + 数据范围注入（ThreadLocal 或参数增强）。
• MaskingAspect：日志脱敏，按字段规则处理（手机号、身份证、token）。

配套约束：

• 统一的上下文对象（如 RequestContext）承载 traceId、tenantId、operatorId。
• 统一的异常与错误码体系（枚举 + 领域异常）。
• 统一的日志字段规范（JSON log、固定 key）。

适用边界：什么时候不该用 AOP

• 逻辑与业务强绑定且需要显式可见（例如核心定价、风控决策），隐藏在切面里会降低可读性与审计性。
• 需要改写控制流且非常复杂（跨多步状态机），AOP 可能让调用路径难以追踪。
• 极致性能路径（纳秒级/微秒级要求）下，代理与反射开销需要评估，必要时用编译期织入或显式调用。

一个落地小案例（文字版）

在“创建订单”场景里常见组合是：

• Controller：生成 traceId、记录访问日志、入参脱敏。

• Service createOrder()：@Idempotent 保证重复提交不重复下单；@Transactional 保证订单与库存扣减原子；

  • @Audit 记录“用户创建订单”的审计事件；MetricAspect 记录耗时与异常。

• 外部支付调用：在支付 Client 方法上织入 Retry/CircuitBreaker，并记录第三方调用耗时与错误码。

这样业务代码只保留“下单这件事”的关键路径，治理策略集中在切面里，变更也集中发生。