1. 从这条数据是谁改的到自动化审计痛点在哪里先讲一个我接手过的模拟项目X的真实场景。当时系统里有一张订单表运营部门隔三差五跑过来问某个订单的状态为什么从待审核变成了已取消是谁改的什么时候改的改之前的值是什么当时代码里的现状是每个Service的方法里都手动写一段日志把操作人、操作时间、变更内容塞到一个审计表里。一开始还好后来方法多了日志格式五花八门有的记录了操作人但没记录旧值有的记录了一句话描述但根本没法还原字段级别的差异。更要命的是新来的同事经常忘记写这段日志审计数据断断续续运营一问就卡壳。这种需求在业务系统里太常见了术语叫数据变更追踪或审计日志本质上要回答四个问题谁、什么时候、对哪个业务实体、做了什么改动。改动要到字段级别最好能精确到订单金额从100元变为90元这种程度。我当时的第一反应是去改所有Service方法每个方法里手动对比旧值和新值然后组装变更记录。但很快放弃了理由有几点一是工作量太大几十个核心方法都要动一遍二是对比逻辑分散在各处以后想统一调整格式比如增加版本号、增加租户ID就得满世界改三是侵入性太强业务代码里塞满了与业务无关的日志逻辑代码可读性直线下降。后来我确定了用SprinBoot AOP 自定义注解这套组合来做。思路很朴素在需要追踪的方法上打一个注解用一个统一切面拦截这些方法在方法执行前拿一次旧值快照在方法执行后拿一次新值快照然后做字段级对比差异自动写入变更记录表。业务代码里只需要加一个注解不用改任何业务逻辑这天然就把横切逻辑从业务代码里抽离出来了。这篇文章我会把完整的落地过程拆开讲包括自定义注解怎么设计、切面怎么拦截、字段对比怎么做才不漏不错、事务和异步场景会踩哪些坑以及我把这套方案放到生产环境后复盘出的几个重要细节。内容适合已经会用SpringBoot做基本CRUD、但对AOP实战还不熟悉的后端开发也适合正在为审计日志怎么写才优雅发愁的团队参考。2. 方案选型为什么是注解 AOP而不是拦截器、监听器或数据库触发器在确定方案之前我其实比较过几条常见的技术路线每一条都有它的适用场景但放在通用、可复用、侵入性小这三个诉求下注解加AOP的胜出优势很明显。2.1 几种常见方案对比先看数据库触发器。触发器在数据库层面记录变更有一个天然优势无论应用层通过什么方式改数据后台任务、手动SQL、另一个系统直连都能被捕获。但缺点是业务逻辑会散落到数据库里以后想要在变更记录里补充操作人、来源IP这类应用层上下文就非常吃力因为触发器拿不到这些信息。而且触发器维护起来比其他方案更隐蔽很多人接手项目时根本不知道数据库里还埋着这么一层逻辑。对小团队来说这属于可控性差的方案。再看MyBatis拦截器或Hibernate事件监听器。这类方案能拦截到ORM层的持久化操作从技术上讲很底层能覆盖到所有实体变更。但我最终没有选它原因很实际拦截器拿到的是参数对象和SQL信息但哪个字段是业务主键哪个字段需要参与对比操作人是多少号员工这些信息它都不知道还是得靠额外的配置或约定去推断。而且拦截器作用范围太广很难精细控制这个方法我要追踪、那个方法我不追踪。然后是Spring的事件监听机制。发布一个领域事件然后在监听器里记录变更这个思路很干净符合领域驱动设计的味道。但它要求业务代码里主动发布事件本质上还是侵入式的只不过侵入点从Service方法移到了事件发布。对大量存量方法来说改造量并没有减少。最后落在自定义注解 AOP切面上。它的核心优势是声明式我要追踪哪些方法只需要在方法上打一个注解追踪逻辑全部收敛到切面里。业务方法本身完全不需要知道有人在记录我的变更这就把横切关注点彻底隔离了。相比拦截器方案它可以精确控制方法粒度相比事件方案它不需要业务代码主动配合相比触发器它能拿到完整的应用上下文。2.2 三层结构注解做标记AOP做拦截快照对比做差异这套方案整体可以拆成三个层次我建议在设计时脑子里始终有这张三层图第一层是自定义注解。它只做一件事标记这个方法需要被追踪同时携带一些元信息比如属于哪个业务模块、业务对象的类型、怎么从参数里提取业务ID、操作人从哪里拿。注解本身不包含任何逻辑它更像是一个说明书。第二层是AOP切面。切面拦截所有标注了该注解的方法在方法执行前读取参数、生成旧值快照在方法执行后拿到返回值或修改后的参数对象、生成新值快照。快照本质上就是对象序列化后的某个Map结构或JSON字符串保存的是那一刻对象的状态。第三层是字段对比器。它负责比较新旧两个快照输出一个结构化的变更明细列表比如字段名、字段描述、旧值、新值。这一步是整个方案的技术核心对比逻辑的健壮性直接决定审计数据的质量。我见过很多方案最后看起来能用但不敢信问题多半出在对比器上——日期格式不一致就误报差异、枚举序列化方式不同就全字段飘红、嵌套对象一改动就整个子对象被标记为变更。三层各司其职互不耦合。注解可以随时打在任何方法上切面负责统一调度对比器可以单独做过单元测试。后面我把每一层的实现细节都过一遍代码可以直接抄。3. 核心实现自定义注解、切面与字段对比器下面进入正题。我会用一个模拟的订单模块来演示业务实体是一个Order对象需求是修改订单信息的接口需要自动记录改了哪些字段、从什么值改成什么值、谁改的。3.1 第一步定义一个携带元信息的自定义注解先上注解的代码package com.example.audit.annotation; import java.lang.annotation.*; /** * 数据变更追踪注解 * 标注在需要记录字段变更的Service方法上 */ Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) Documented public interface ChangeTrack { /** * 业务模块比如 order、user、product */ String module() default ; /** * 业务对象类型用于指定要对哪个参数做快照 * 默认取第一个参数 */ Class? entityClass() default Void.class; /** * 从方法参数中提取业务ID的SpEL表达式 * 比如 #order.id 表示取第一个参数的id字段 */ String businessId() default ; /** * 操作人的SpEL表达式优先从方法参数取比如 #operatorId * 为空时自动从当前登录上下文获取 */ String operator() default ; }有几个设计细节我要强调一下Retention(RetentionPolicy.RUNTIME)