这段时间在整内部权限系统的审计改造需求清单里有一条写得很简单所有关键操作必须留痕。谁操作、什么时候操作、改了什么、结果成功还是失败必须有记录而且要能按条件查询、导出、长期保存。我第一版用的是最直接粗暴的方案在每一个Controller方法里硬编码日志代码写完三个接口后我直接把这个方案推翻了代码重复不说漏记、错记几乎是必然的。后来换成SpringBoot配合AOP做了一套注解驱动的操作日志模块异常信息、入参出参、执行结果全部自动收集才算是把这个需求踏实落地。这套方案很适合大多数中小型系统的后台管理场景只要你在用SpringBoot并且正被“日志埋点散落各处”这件事折腾得不轻那这篇里的思路和代码可以直接拿去改。1. 为什么选AOP做操作日志而不是靠硬编码1.1 硬编码埋点的问题刚开始写这个功能我脑子里蹦出来的第一个方案是在每个方法开头调一次日志服务方法结束再来一次。但从需求把“记录关键操作”扩展到“记录参数”“记录异常”“记录耗时”之后麻烦就全暴露了。一个Controller方法里可能要插入三四处日志调用如果方法的入参是十几个字段的对象你还得手动挑哪些要记、哪些不记。一类操作还好几十个接口、几百个方法写下来重复代码量非常可观。更关键的是日志记录一旦和业务代码混在一起改起来特别容易出错例如在查询方法里调整缓存逻辑时顺手就把日志字段写丢了。线上排查问题时找代码埋在哪个角落就要花半天。这还没算另外一个隐患写日志的人未必熟悉所有接口的业务有人会把手机号、身份证号这种敏感字段完整打出来。一旦日志库泄露这批数据就是第一责任现场。硬编码日志由于分散在各处想做统一的脱敏和截断也很麻烦每次都要在每个埋点里单独处理。1.2 AOP适合做日志的底层原因AOP在面向对象之后提供了一种解决横切关注点的思路。日志、事务、权限、参数校验这些逻辑并不属于核心业务逻辑但又散布在每一个业务方法里最适合用切面统一接管。SpringBoot里的AOP基本原理是动态代理Spring容器启动时会给被切面匹配的Bean生成代理对象你调用业务方法时实际先进代理对象代理对象在invoke方法中执行各个切面逻辑最后才转调真正的目标方法。这样日志采集代码只需要写在一个切面类里不用入侵任何业务方法。业务方法只关心自己的业务逻辑日志归日志两者互不拖累。这带来的直接好处是一致性不会出现A接口记了日志、B接口忘了记的情况因为规则只存在于切面表达式和注解里。1.3 过滤器、拦截器为什么不能直接替代有人会问Servlet层面有FilterSpringMVC里有HandlerInterceptor这两个也能在请求过来时做记录为什么偏偏用AOPFilter有一个致命问题在Filter里很难拿到被调用方法的方法名、注解以及反序列化后的参数对象。它顶多能拿到HttpServletRequest想拼出完整的操作参数需要自己做大量的解析例如从body里读JSON再反序列化体感极差。Interceptor比Filter好一点能拿到HandlerMethod可以从里面读取Method和注解但Interceptor只作用于Controller层如果业务逻辑下沉到Service层在Service里记录日志就无能为力了。AOP的切入点是任意SpringBean方法既能切Controller层也能切Service层甚至同时切多个层不会因为代码结构调整而丢日志。1.4 Spring AOP和AspectJ怎么取舍用SpringBoot做AOP时默认依赖的是Spring AOP基于动态代理实现。目标类实现了接口时会用JDK动态代理没有接口时会用CGLIB生成子类代理。如果你只需要在Spring管理的Bean方法上做切面Spring AOP完全够用不需要引入AspectJ的编译期织入。AspectJ强大在编译期或加载期织入能处理一些更底层的切面需求但配置和构建过程复杂不少。对一个操作日志模块来说切面只会落在Service或Controller方法上Spring AOP能全覆盖没必要给自己加复杂度。如果碰到代理不生效优先排查方法是不是private修饰或者对象是不是类内部new出来的而不是一上来就怀疑AOP能力不够。2. 整体设计注解、切面、存储三层结构2.1 用注解的方式标记哪些方法需要记录设计操作日志时第一个要解决的问题是如何告诉AOP“哪些方法需要被记录”。我选择的是自定义注解加切面注解的方式在需要记录的方法上打一个OperationLog声明模块、操作类型、描述等信息。为什么用注解而不是像execution(* com.demo.controller..*.*(..))这种纯切点表达式纯切点表达式能圈定一个大范围但问题是太粗。一个Controller类里可能有增删改查也可能有纯粹的查询下拉框数据这类查询如果全记日志量会翻好几倍。注解的好处是精确控制它把“是否记录”变成了一个显式的元数据声明。维护代码的人看到这个注解就能明白当前方法属于需要审计的关键路径。注解里可以设计的属性包括module模块名、type操作类型、description操作描述、recordParams是否记录参数、recordResult是否记录返回值。把这些做成可配置项是因为有些操作涉及大数据量导出结果集根本不适合落库这时候可以在注解层面关掉结果记录实现比在切面里写一堆if判断要清晰。2.2 切面类的职责划分切面类承担的工作可以拆成四块采集、过滤、转换、落库。采集阶段获取方法签名、注解信息、入参、返回值、异常、耗时、操作人和IP。过滤阶段决定哪些参数需要记录哪些字段需要脱敏哪些结果太长需要截断。转换阶段把对象序列化成JSON字符串把异常堆栈整理成精简的errorMsg。落库阶段构造日志实体异步写入存储。我见过一些团队把这段逻辑全写在一个doAround方法里上百行的代码全堆在一起后续想加一个字段都要在围绕方法里反复改非常容易破坏主流程。建议是切面类只做编排真正构造日志、序列化参数、脱敏的逻辑拆成独立的工具类或Service每个方法只干一件事。这样即使运行期出现日志组件报错也不会影响业务链路。2.3 存储方案怎么选操作日志是典型的写多读少数据写入频率高查询通常按操作人、模块、时间段来检索偶尔要做导出。存储方案需要结合团队现状来选下面是一个简单的对比。存储方案优点缺点适用场景MySQL单表实现简单事务好控制可以精确查询数据量大后查询变慢需要归档中小系统、日操作量几万以内MongoDB文档模型适合存JSON写入快扩展方便团队需要额外维护一套数据库日志结构变化多、查询条件复杂Elasticsearch全文检索效率高适合海量日志部署运维成本高字段映射有学习成本日志量百万级以上、需要全文搜索只打日志文件零存储成本接入简单查找麻烦没法按字段结构化查询单纯排查问题不做审计追溯就常规后台系统来说MySQL单表是性价比最高的选择。数据量大了之后可以做按月分表或者把超过半年的数据归档到冷表。实际项目中一个业务操作日志表放个几百万行数据配合建好索引和限制查询范围性能完全可控。如果一开始就上ES反而会把项目复杂度搞上去尤其是不熟悉ES的团队光字段映射和写入调优就能磨掉不少时间。3. 核心细节操作人、参数获取、异步落库3.1 怎么获取操作人操作人信息是审计日志的灵魂记录不到操作人这条日志基本没价值。不同系统的用户信息存放方式不同常见的是Spring Security上下文或者是自己写的UserContext线程变量再或者在请求头里放一个token由网关或过滤器解析后放入上下文。我在切面里会专门写一个getOperator()方法先从ThreadLocal里拿当前登录用户拿不到再解析请求头的用户信息做成一个兜底链。因为后台系统里经常有定时任务、MQ消费者在跑这些调用没有HttpServletRequest如果只依赖请求头定时任务触发的操作日志就记录不到操作人。对比一下两种做法硬编码日志时每个方法都要自己调UserContext.get()用AOP后操作人获取逻辑集中在切面里业务方法完全不用关心。这也体现了抽公共逻辑的价值。3.2 参数和返回值怎么记录才安全参数记录常用Jackson或Fastjson把对象序列化成JSON字符串。但如果直接对所有参数做序列化很可能踩两个坑。第一个坑是序列化异常。某些实体类里存在MultipartFile、HttpServletResponse这类不可序列化对象直接序列化会抛异常。在切面里必须做类型过滤遇到这些类型就跳过参数记录或者改成只记录文件大小和文件名。第二个坑是敏感字段。用户列表查询如果带上了用户手机号日志里会完整记录手机号这属于数据泄露。处理办法是自定义一个脱敏工具对JSON字符串里的手机号、邮箱、身份证做正则替换。更优雅的做法是给每个字段标注脱敏注解序列化时统一处理但这要求团队内部约定一致。最保守的方案是设置参数记录的最大深度深度过大的对象只保留第一层字段避免把嵌套实体全量打出。3.3 为什么日志落库要异步如果每次操作都在业务事务里同步插入日志有两个概率很高的问题日志表写入失败可能导致业务主流程失败日志插入耗时拉长事务时间影响接口性能。实际操作日志系统的写入频率远高于普通业务表一个后台管理员一天可能触发几百次日志写入。同步写库在高并发下就是累赘。我当时把日志落库做成了Async异步调用单独使用一个线程池业务方法执行完之后切面把日志对象塞进队列由异步线程执行插入。要注意的是异步方法不能和主业务共用同一个事务传播否则日志逻辑还是在原事务里阻塞。可以在异步方法上明确使用REQUIRES_NEW让日志插入独立成一个新事务。如果担心异步线程里拿不到操作人信息那就在构建日志对象时把操作人提前写入实体字段避免在异步方法里再查一次上下文。异步也带来一个副作用日志的入库时间会略晚于业务操作时间。如果在极端情况下应用直接崩溃最后几秒的内存日志会丢失。对大多数后台管理项目来说这种损失可以接受。如果强审计场景不允许丢失任何日志可以考虑本地文件先落盘再加异步上报但复杂度会高很多。3.4 切面执行顺序怎么保证一个方法上可能同时存在事务切面、操作日志切面、权限校验切面。Spring AOP支持通过Order控制切面的相对顺序。我的经验是日志切面要尽量放在最外层也就是Order(1)。这样日志能包住后面的权限校验和业务逻辑权限校验失败也能记录到一次“越权尝试”这对审计非常有价值。事务切面一般放在日志切面内侧否则日志记录如果抛异常会影响事务提交。如果你用多个切面务必在项目里建立切面顺序约定。线上最常出现的一个坑是日志切面放在最内层业务方法抛异常后日志切面还没开始执行异常已经被外层吞掉最终日志缺失。遇到这种问题不要直接加代码先理清所有增强的嵌套顺序。4. 实操完整实现一套注解式操作日志4.1 项目依赖准备创建一个SpringBoot项目核心依赖就这几个。我额外加了MyBatis-Plus和MySQL驱动主要是为了演示持久化你可以换成JPA或者别的ORM。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-aop/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency这里要特别提醒spring-boot-starter-aop很容易被忽略很多人以为有了SpringBoot就不用再引AOP依赖。实际上如果你只用核心依赖没引入starter-aopAspect注解和Around都不会生效因为缺少了切面所需的AspectJ库。排查AOP不生效时第一件事就是确认这个依赖是否在pom里。4.2 建一张操作日志表日志表字段按审计需求来设计核心是操作人、模块、类型、描述、请求参数、返回结果、异常信息、耗时、状态、时间。以下是建表SQL可以作为参考模板。CREATE TABLE sys_operation_log ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, operator_id varchar(64) DEFAULT NULL COMMENT 操作人ID, operator_name varchar(128) DEFAULT NULL COMMENT 操作人名称, module varchar(64) DEFAULT NULL COMMENT 所属模块, operation_type varchar(32) DEFAULT NULL COMMENT 操作类型, description varchar(255) DEFAULT NULL COMMENT 操作描述, class_name varchar(255) DEFAULT NULL COMMENT 被记录的类名, method_name varchar(255) DEFAULT NULL COMMENT 被记录的方法名, request_uri varchar(255) DEFAULT NULL COMMENT 请求URI, http_method varchar(16) DEFAULT NULL COMMENT 请求方式, ip varchar(64) DEFAULT NULL COMMENT 客户端IP, params text COMMENT 请求参数JSON, result text COMMENT 返回结果JSON, error_msg text COMMENT 异常信息, execute_time bigint DEFAULT NULL COMMENT 执行耗时毫秒, status tinyint DEFAULT NULL COMMENT 1成功 0失败, create_time datetime DEFAULT NULL COMMENT 操作时间, PRIMARY KEY (id), KEY idx_operator_create_time (operator_name, create_time), KEY idx_module_create_time (module, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT系统操作日志表;索引建议不要建太多日志表是写入量比较大的表索引过多会影响写入性能。上面两个联合索引基本覆盖最常见的查询场景按操作人查时间范围、按模块查时间范围。如果后续要频繁按操作类型查再考虑加索引。4.3 自定义注解和实体类先定义一个注解属性按需要设置。Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface OperationLog { String module() default ; String type() default ; String description() default ; boolean recordParams() default true; boolean recordResult() default false; }实体类对应数据库表这里用MyBatis-Plus的注解标注表名和主键。Data TableName(sys_operation_log) public class SysOperationLog { TableId(type IdType.AUTO) private Long id; private String operatorId; private String operatorName; private String module; private String operationType; private String description; private String className; private String methodName; private String requestUri; private String httpMethod; private String ip; private String params; private String result; private String errorMsg; private Long executeTime; private Integer status; private LocalDateTime createTime; }4.4 切面类核心实现切面类不直接操作SQL它只负责装配数据。核心方法用Around包裹目标方法在proceed()之前记录开始时间在finally里构造并异步保存日志。逻辑必须放在finally里这样不管是正常返回还是抛出异常日志都能写进去。Aspect Component public class OperationLogAspect { Autowired private OperationLogSaveService operationLogSaveService; Around(annotation(operationLog)) public Object around(ProceedingJoinPoint joinPoint, OperationLog operationLog) throws Throwable { long startTime System.currentTimeMillis(); boolean success true; String errorMsg null; Object result null; try { result joinPoint.proceed(); return result; } catch (Throwable e) { success false; errorMsg e.getMessage(); throw e; } finally { try { SysOperationLog logEntity new SysOperationLog(); buildBaseInfo(logEntity, joinPoint, operationLog); buildRequestInfo(logEntity, joinPoint, operationLog); logEntity.setResult(serializeResult(result, operationLog.recordResult(), success)); logEntity.setErrorMsg(errorMsg); logEntity.setExecuteTime(System.currentTimeMillis() - startTime); logEntity.setStatus(success ? 1 : 0); logEntity.setCreateTime(LocalDateTime.now()); operationLogSaveService.saveAsync(logEntity); } catch (Exception e) { log.error(记录操作日志失败, e); } } } }buildBaseInfo负责填充操作人、模块、类型等基础信息buildRequestInfo负责序列化方法入参、IP、URI等请求信息。序列化时一定要捕获异常可以加一个保险措施如果整个参数序列化失败就写入一条失败说明而不是让异常信息直接中断整个日志记录流程。关于IP获取常规做法是取X-Forwarded-For请求头如果没有再取getRemoteAddr()。注意一个细节X-Forwarded-For是用户可控的请求头如果直接信任它可能出现伪造IP的情况。如果系统对IP真实度要求高需要在网关层统一覆盖。4.5 操作日志保存服务与异步线程池日志保存的Service里我把写入方法标记为Async指定一个专用线程池。public interface OperationLogSaveService { void saveAsync(SysOperationLog operationLog); } Service public class OperationLogSaveServiceImpl implements OperationLogSaveService { Autowired private OperationLogMapper operationLogMapper; Async(logExecutor) Override public void saveAsync(SysOperationLog operationLog) { operationLogMapper.insert(operationLog); } }配置一个容量有限的线程池避免日志写入把核心业务线程池拖垮。核心线程数不用太高因为日志操作本身很快。Configuration public class LogAsyncConfig { Bean(logExecutor) public Executor logExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(2); executor.setMaxPoolSize(4); executor.setQueueCapacity(1000); executor.setThreadNamePrefix(op-log-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }这里要解释一下为什么拒绝策略选CallerRunsPolicy。如果日志队列已经满了直接丢弃会丢日志抛出异常又会影响业务CallerRunsPolicy会让提交日志的线程自己执行插入相当于一个降级策略。它的代价是主线程可能被日志写库阻塞一会儿但远比丢日志或者炸掉主流程可控。4.6 业务方法上使用日志注解使用时只需要关注注解上的几个字段。RestController RequestMapping(/api/user) public class UserController { OperationLog(module 用户管理模块, type 增加, description 新增用户) PostMapping public ResultVoid createUser(RequestBody UserCreateRequest request) { userService.createUser(request); return Result.ok(); } OperationLog(module 用户管理模块, type 删除, description 删除用户, recordParams true) DeleteMapping(/{id}) public ResultVoid deleteUser(PathVariable Long id) { userService.deleteUser(id); return Result.ok(); } }新增用户场景我把recordResult留为默认的false因为返回结果只有成功标志业务价值不大。删除用户同理。但如果是更新操作通常建议recordResult true方便以后追溯操作前后结果是否异常。4.7 查询接口怎么支持日志管理日志表建好、数据开始写入之后需要有一个管理后台查询界面。接口的逻辑不复杂按操作人、模块、时间范围、状态做组合查询支持分页。RestController RequestMapping(/api/log) public class OperationLogController { Autowired private OperationLogMapper operationLogMapper; GetMapping(/page) public ResultIPageSysOperationLog page(PageSysOperationLog page, RequestParam(required false) String operatorName, RequestParam(required false) String module, RequestParam(required false) String status, RequestParam(required false) String startTime, RequestParam(required false) String endTime) { LambdaQueryWrapperSysOperationLog wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(operatorName), SysOperationLog::getOperatorName, operatorName) .eq(StringUtils.hasText(module), SysOperationLog::getModule, module) .eq(StringUtils.hasText(status), SysOperationLog::getStatus, status) .between(StringUtils.hasText(startTime) StringUtils.hasText(endTime), SysOperationLog::getCreateTime, startTime, endTime) .orderByDesc(SysOperationLog::getCreateTime); return Result.ok(operationLogMapper.selectPage(page, wrapper)); } }查询日志的接口本身也应该记录不过通常这类管理接口不需要打日志不然就变成日志套日志了。如果审计要求连查询日志都要记录可以单独设计一个日志浏览表记录谁查过哪些日志这个一般只有过审要求极高的系统才会做。5. 实际踩坑AOP日志模块的常见问题与排查5.1 内部方法调用导致切面不生效这是一个经典问题。Service public class UserService { public void createUser(UserCreateRequest request) { this.updateUserInfo(request); } OperationLog(module 用户管理, type 更新, description 更新用户信息) public void updateUserInfo(UserCreateRequest request) { // 业务逻辑 } }这样写在业务逻辑上毫无问题但AOP切面不会执行。因为updateUserInfo是被this直接调用的而this指向原始对象不是代理对象。Spring AOP的拦截只发生在外部通过代理对象调用时内部方法调用等于绕过了代理。解决办法最常用的是从Spring容器中重新获取代理对象或者把自己注入进来。Service public class UserService { Autowired private UserService self; public void createUser(UserCreateRequest request) { self.updateUserInfo(request); } }我在项目里建议的方法更直接把需要记日志的操作封装到独立Service并由Controller或外层Service调用避免内部自调用。这样做还能顺带把业务逻辑模块拆得更干净。5.2 日志记录的异常影响主流程切面里的日志代码如果没做好异常隔离很可能成为事故源头。比如序列化参数时抛了一个StackOverflowError或者日志线程池满了之后回调阻塞都可能导致业务接口变慢甚至失败。处理原则很简单日志代码不能影响主业务。切面里的finally块要加try-catch并且捕获后只打印一条WARN日志不向上抛。异步线程池的拒绝策略要慎用AbortPolicy因为它的行为是直接抛异常这在日志写入场景下太危险了。如果你发现业务接口偶发超时并且时间点和日志模块上线时间吻合优先检查日志写入是否同步执行、序列化耗时是否过长。我就遇到过因为某次参数对象特别大Jackson序列化花了近一秒钟同步写库后整个接口慢到不可接受的情况。后来统一改成异步加结果截断问题才消停。5.3 切面顺序问题导致日志和事务相互干扰默认情况下Spring AOP切面的执行顺序是不确定的。如果日志切面和事务切面都作用于同一个方法可能出现日志的Around包在事务外面也可能包在事务里面。日志包在事务外面通常问题不大最多是日志保存滚到了事务提交前如果事务最终回滚日志里会记录一次实际未生效的操作。日志包在事务里面就有风险了因为日志代码一旦发生异常可能会触发事务回滚把明明成功的业务操作也回滚掉。解决方法是给日志切面加Order(1)让它尽量靠外。事务切面的Order值一般保持默认或者设得更大一点。我在项目中习惯把所有横切关注点排列成日志切面、权限切面、缓存切面、事务切面这样日志能覆盖最完整的方法生命周期。5.4 敏感字段泄漏问题日志里最容易翻车的是敏感字段。用户手机号、邮箱、身份证这类信息如果直接进日志库等于是给数据安全埋雷。最基本的做法是在序列化时做字段过滤比如Jackson的JsonIgnore配合视图或在配置中排除字段。但更稳妥的方案是日志切面里加一道脱敏过滤序列化完成后对JSON字符串中匹配手机号、身份证号等正则的数据做掩码替换。脱敏需要注意替换时机必须在字符串层面整体做不能只对对象字段做。因为日志里的JSON可能是嵌套结构只处理第一层字段嵌套对象里的敏感信息照样会漏出来。这块没有万能的自动化方案脱敏规则要和业务团队定清楚形成一份敏感字段清单并持续维护。5.5 日志表数据量增长太快操作日志模块跑一段时间后你会发现日志量增长远超预期。一个每天几千次操作的系统中几个月就能攒几十万行数据。如果不做处理日志表的查询会逐渐变慢。我常用的手段是三类分表、归档、定期清理。按月分表是最实用的但查询时需要根据时间范围路由到对应的表。归档是把超过半年的数据迁移到历史表或者冷存储日常查询只访问热数据。定期清理适合日志价值不高的场景直接删除超过保留期的数据但删除历史日志这件事在审计严格的系统里要先确认合规性。如果你的日志查询条件很固定比如主要查最近一个月数据还可以在查询接口里强制增加默认时间范围避免一次全表扫描。5.6 注解属性太多导致使用不规范OperationLog如果属性太多团队成员使用时容易出现随意填写的情况比如module字段写“用户”、“用户管理”、“用户模块”最后查询时没法统一筛选。我的建议是module和type字段定义成枚举或者定义常量类在注解里写module LogModule.USER。这样既能约束使用规范也能在切面里直接比较不用解析字符串。如果团队里有人嫌枚举麻烦至少也要在代码审查时把关保证同一类操作的模块名全库一致。6. 扩展思考操作日志能做的不只是留痕6.1 操作轨迹还原与审计当你把操作日志做成AOP模块之后日志数据的价值会随着时间显现。最基础的用途是出了事故能定位谁做了什么。更进一步你可以把同一个人对同一条业务数据的操作日志按时间线串起来形成一条完整的操作轨迹。比如一个订单从创建、修改、审核、删除每一步都会留下日志。把同一订单ID的操作记录连起来看就可以还原这个订单在整个生命周期里发生了什么。这需要日志数据结构里加一个业务唯一标识字段比如orderId、userId。设计日志表时如果能把业务主键独立成一个字段后续做轨迹还原会非常方便。6.2 结合全文检索引擎做搜索当日志量达到百万级时MySQL单表的模糊查询会明显变慢。此时可以把日志数据异步同步到Elasticsearch利用它的全文检索能力快速搜索参数里包含某个关键词的所有操作记录。实操上并不复杂日志异步入库之后通过MQ或者定时任务把日志数据同步到ES。查询接口做双存储架构列表页查ES详情页按主键回查MySQL。这样既保留结构化存储的可靠性又提升了搜索效率。需要注意ES的索引字段要和查询条件匹配好不要把所有字段都设为text类型否则精确匹配会出问题。6.3 异常操作告警操作日志里可以分析出高风险行为。比如短时间内频繁调用删除接口、某个用户在非工作时段执行了敏感操作、某个接口连续出现失败这些都能通过定时统计日志数据发现并产生告警。我在项目中做过一个简单规则引擎定时任务每隔五分钟扫一次日志表统计各个维度的异常指标超过阈值就发钉钉或企业微信告警。这个功能在安全审计场景下很有价值而且逻辑并不复杂核心就是复用已有的操作日志数据。相比单独去业务表里查数据日志表的结构已经很统一做聚合分析很方便。6.4 数据归档与长期合规审计数据通常要求保存较长时间但热库不可能一直放全量数据。一种相对成熟的做法是把日志分为热数据和冷数据热数据保留最近三个月三个月以前的定期归档到冷环境。归档操作也要做成一个独立任务建议在业务低峰期执行。归档时不能只搬数据还要把索引一起迁移否则冷数据查询起来非常痛苦。如果公司有大数据平台最理想的模型是把日志通过消息队列实时同步到数据仓库热库只保留短时间内的数据供管理后台检索历史数据在大数据平台里做长期分析。这套架构虽然重一些但能解决长期合规问题。我最后想分享的几点体会操作日志这个需求看起来简单真正写得顺滑且能持续维护其实依赖设计和工程规范的程度远高于依赖代码工程量。我踩过几次坑之后的体会是日志模块的成败一半在切面设计一半在团队约定。切面设计决定了日志能否自动采集、自动脱敏、异步落库团队约定决定了日志里的模块名、操作类型、描述是否规范一致这直接影响后续审计和排查效率。另一个很实用的经验是切面里所有可能出错的地方都要用兜底try-catch包住日志记录永远不能影响主业务宁可少记一条也不能把接口搞挂。如果你正准备给项目加操作日志功能建议从最小可用版本开始一张表、一个注解、一个切面类先把链路跑通再去考虑分表、告警、全文检索这些进阶能力。