@AspectJ 全解：切点表达式与五种通知

先说人话。你的业务代码里总会反复出现同一批「跟业务无关的活儿」：打日志、算耗时、查权限、发告警。如果不做处理，这些代码就得手抄进每一个方法，几十个方法抄几十遍，规则一改就要翻全项目。切面（AOP）干的事就一件：把这些重复的杂活从方法里抽出来，集中写一份，然后由容器在运行期自动把它们垫到方法调用的前后。你写的业务方法一个字都不用改，也不用知道自己被垫了什么。

要用这套机制，你必须先分清五个词。连接点（join point）是「一次真实的方法调用」这个时刻；切点（pointcut）是一段表达式，用来圈定「哪些连接点归我管」；通知（advice）是你真正想多做的这段代码；切面（aspect）是切点 + 通知打包成的那个类；织入（weaving）是容器把通知接到调用路径上的动作。这五个词的关系只有一句话：切面 = 在哪拦（切点）+ 拦下来做什么（通知），织入负责把它们接上。

学完这一篇，你要能回答三个问题：

1. execution( com.example.service...*(..)) 里每个符号各自管什么？少写一个点会怎样？
2. 五种通知谁先进、谁后出？为什么只有 @Around 能改返回值、能把异常吃掉？
3. 切面「静默不生效」有哪四种成因，第一步该看什么才能确定不是自己的错觉？

写切面之前先得把开关打开。纯 Spring 项目里通常是这一行：

切点是切面里最需要练手感的部分。核心是 execution，它的完整语法可以先记成这样一个骨架：

除了「返回类型、方法名、参数」这三段是必需的，其余都可以省略或用 *、.. 通配。下面五个例子覆盖了日常绝大多数写法：

除了 execution，还有一批按「更省事」的场景设计的切点指示符，区别在于它们匹配的「维度」不同：

多个切点可以用逻辑运算符拼起来，读起来很像自然语言：

通知就是插在切点匹配到的方法上的那段代码。Spring AOP 提供了五种，关键区别在于它们的「权限」：

一句话提炼：只有 @Around 是「全能选手」——它拿到 ProceedingJoinPoint，可以先改参数、决定要不要调用目标、改写返回值、甚至把异常吞掉。其余四种都只能「观察」和「记录」，改不了入参也改不了出参。

这张对照图把上面那行的意思摆成了两侧：左边是「只能看不能动」，右边是「什么都能动，但责任也在你」。选型的判断依据从来不是「哪个更高级」，而是「这次到底要不要改结果」：

通知方法怎么拿到「当前调用的信息」？靠参数绑定。下面是一个五脏俱全的切面类：

「按名字对齐」这一步到底怎么发生的，六帧动画拆开：注意第 ④ 帧——注解里的字符串和形参名逐个比对，这里没有表达式语言参与，纯靠名字：

正因为这里没有表达式，很多新手会把 returning = "result" 和 @Cacheable(key = "#user.id") 里的 #{} 当成同一套语法，然后写出 returning = "#result" 这种静默失效的怪东西。那是 SpEL，另一套语言：它有自己的根对象（#root / #this）、集合筛选与投影、三元与安全导航，写错的报错也完全不同。切到最后一档能一次看完三种典型写错：

把所有通知挂到同一个方法上，谁先谁后？直接跑一段看结果最清楚：

多个切面同时匹配一个方法时，顺序由 @Order 决定：

「明明写了切面，怎么就是不执行」是切面开发的头号问题。按下面这张表逐行排查，八成能定位：

排查的第一手段永远是日志：把 logging.level.org.springframework.aop=DEBUG 打开，容器会打印出每个 Bean 被哪些切面、用什么代理类型处理，切点匹配不上时会给出「does not match」的原因。

下面这个演示把通知链的执行顺序可视化出来。切到「异常路径」再跑一遍，可以直观看到 @AfterThrowing 是怎么替换掉 @AfterReturning、而 @After 又是怎么在两条路径上都执行的：

上面那一支看的是「代理怎么转」，第六节那张时序表还得配一支专门跑通知顺序的实验。advices 把五种通知全挂上同一个方法，normal 与 error 各跑一遍，两条路径的差异一眼就出来：

前面全是文字，这一节全部可以点。四个实验按「先看到现象、再理解机制、最后搞清顺序」排列，每个都能自己切参数。

第一个实验回答第〇节那个「快递分拣」类比：同一段包路径写进 execution 和 within，含义完全不同。切到「execution 各段」能看到逐段核对的过程；切到「为什么没匹配上」会列出静默失配的五种成因——这是新手最容易卡住的一格，因为它不报任何错：

「段与段怎么核对」这件事，光看动画还是太快。把它摊成单步台：左边是一个候选方法与一条表达式，右边同步刷新「此刻判到哪一段、结论是什么」。连点下一步，盯住第 ⑤ 步——整条表达式在这里就已经短路了，后面两段根本没被判断：

第二个实验专门处理「注解到底贴在方法上还是类上」。@annotation 与 @within 名字只差一个词，效果南辕北辙；这一支还会告诉你一个隐形杀手：Java 的方法注解不会被实现类自动继承，只写在接口方法上常常匹配不到：

第三个实验是织入前后的对照——同样是 userService.save("张三") 这一次调用，没有切面时调用栈只有一层、方法体里混着 log/try-catch/计时；织入切面后调用栈多了三层横切通知，而业务代码一行未改。切到「代理的代价」能看清套壳要付什么（启动更慢、final/private/自调用四种情况增强不了）：

第四个实验解决第六节末尾那个追问：多个切面同时命中一个方法时谁在外层。切到「嵌套执行时序」会把完整链条一步步列出来（Around1 前 → Around2 前 → Before → 目标 → AfterReturning → After → Around2 后 → Around1 后）；切到「顺序颠倒的坑」会展示忘写 @Order 为什么会变成「我机器上好的，CI 上过不去」：

四支实验跑完，剩下的就是把「表达式」和「它圈到的人」练成条件反射。第二节那张表讲的是维度，这一局练的是读一条表达式立刻说出它命中谁、漏掉谁——左右两列各不重复，靠位置猜不出来：

实验做到这里，可以换成命令行自己敲。这台控制台连着浏览器里的同一个容器，回显全部由内核算出来——boot 起容器，beans 看谁被套了壳，lab pointcut nomatch 就是上面那个单步台的完整版：

沙盘左边逐个改「返回类型 / 包深度 / 方法名 / 参数表」四段，右边立刻给出这次能命中哪些方法、以及为什么命不中。把「少写一个点」「() 当成 (..)」这两格亲手选一次，比背十条规则管用：

下面每一行的「报错原文」都可以整段粘进搜索框，别意译、别缩写：

这张表第一行是「静默」，而切点写歪还有另一种命运：当场炸给你看，而且栈顶在 Spring 里、真凶在 AspectJ 的解析器里，读起来格外绕。练一次：

目标：三分钟跑出一个「能看见日志」的完整切面，确认你的工程里 AOP 真的通了。以下五个文件放进一个新建的 Spring Boot 项目即可运行（pom.xml 需包含 spring-boot-starter-aop，或至少有 org.springframework.boot:spring-boot-starter + org.aspectj:aspectjweaver）。

预期输出（==== 那行由 System.out 打印，其余是 slf4j 日志，前缀会带时间与类名）：

只做一件事，然后观察结论：

1. 把切点从 com.example..Service.(..) 改成 com.example..Service.(..)（少一个点）。你会观察到：UserService 若正好位于 com.example 这一层仍会命中，但只要挪进 com.example.service.impl，通知就全灭且不报错——回到第十二节沙盘的 one-star 那一格对照，你会一眼看懂「单层 只吃一层」。
2. 删掉 @Around 里的 return pjp.proceed();，只留 log.info。你会观察到：==== 目标方法执行 ==== 这行彻底消失，接口/返回值变成 null，而程序一句异常都不抛。这就是第十四节第二道自测的现场版。
3. 给 UserService#save 再加一个 MetricAspect（@Order(2)，内容与 TraceAspect 相同但前缀换成 [METRIC]），TraceAspect 标 @Order(1)。你会观察到：日志顺序是 AROUND-IN(Trace) → AROUND-IN(Metric) → BEFORE → 目标 → AFTER → AROUND-OUT(Metric) → AROUND-OUT(Trace)；把两个数字互换，进入与退出顺序必然整体翻转。再把两个 @Order 都删掉，反复重启几次，你会发现顺序开始飘——这就是「幽灵 bug」的养成方式。
4. 把 save 改成 private。你会观察到：通知再次全部消失，同样不报错。原因见 #14 AOP 内核的代理边界。

做一个「耗时归因切面」：不只打印耗时，还要按阈值分级并把慢调用汇总起来。

• 定义注解 @SlowWatch(value = "下单", warnMs = 200, errorMs = 1000)，@Target(METHOD)、@Retention(RUNTIME)
• 写一个切面 @Around("@annotation(slowWatch)")：正常路径打 INFO，超过 warnMs 打 WARN，超过 errorMs 打 ERROR，日志里必须带上方法名、@SlowWatch 的 value、耗时、参数个数
• 用 ConcurrentHashMap<String, LongAdder> 按方法累计调用次数与总耗时，暴露一个 @Scheduled 或在关闭时打印「Top 3 最慢方法」
• 异常路径不许吞：捕获后原样 throw，并额外记一条「失败次数」

验收清单：① 同一个方法分别构造出 50ms / 300ms / 1200ms 三种耗时，日志级别依次为 INFO / WARN / ERROR；② 抛异常时上层仍能收到原异常（用 @AfterThrowing 或 try/catch 验证堆栈未被替换）；③ 把 @SlowWatch 贴到 private 方法上，你能说清为什么不生效且不靠猜；④ 关掉这个切面（去掉 @Component），业务输出与之前完全一致——证明它确实只是「套在外面的壳」。