代码生成器自动填充审计字段

几乎所有开发团队都会遇到一个尴尬的问题：上线一段时间后，发现某条核心业务数据被篡改了，却死活查不出是谁在什么时间动的手脚。查日志发现没记录，查数据库发现"update_time"还是三天前的，最后只能不了了之。这类问题的根源，往往在于审计字段的维护逻辑散落在各个业务方法里，靠人工调用"setUpdateTime(new Date())"来维持。只要有一个地方忘了写，数据的一致性就崩了。

代码生成器自动填充审计字段，本质上不是简单的“帮你写一行set代码”，而是建立一套零遗漏、零人工干预的字段维护机制。它要解决的核心痛点就三个：一是杜绝遗忘，二是统一格式，三是处理批量操作时的传播问题。很多团队用代码生成器只生成了表结构对应的实体类，审计字段还是交给开发人员手动处理，这等于把最该自动化的环节留给了最容易出错的人。

在动手配置代码生成器之前，得先明确哪些字段需要自动填充。最常见的四个审计字段是：创建人、创建时间、最后修改人、最后修改时间。但实际企业级项目里，这个清单往往要扩展。比如涉及多租户的系统，租户ID本质上也是一种审计信息，它标记了数据的归属。再比如需要做逻辑删除的表，删除人、删除时间同样属于审计范畴。还有一些合规要求高的场景，会要求记录数据来源渠道、操作IP地址，甚至操作时使用的设备指纹。

把这些字段梳理清楚后，你会发现它们有一个共同特征：与业务逻辑完全无关，但对数据追溯至关重要。正因为与业务无关，它们才特别适合交给代码生成器在持久层统一处理，而不是散落在Service层的手动赋值里。一个典型的审计字段配置，在代码生成器的模板里应该包含如下元数据定义：字段名、字段类型、填充时机（插入时、更新时、或两者皆有）、值来源（取自当前登录用户、取自系统时间、取自上下文变量）。

第一种模式是数据库默认值加触发器。很多老项目习惯在建表时给"create_time"设"DEFAULT CURRENT_TIMESTAMP"，给"update_time"设"ON UPDATE CURRENT_TIMESTAMP"。这种做法确实简单，但问题也很明显：它只能处理时间字段，处理不了用户ID这类需要从应用层传入的值。而且触发器在数据量大时性能开销不小，出问题排查起来也费劲。代码生成器如果只依赖这种模式，等于把一半的审计责任推给了数据库，应用层该丢的信息还是会丢。

第二种模式是实体类生命周期回调。JPA里有"@PrePersist"、"@PreUpdate"，MyBatis-Plus里有"@TableField(fill = FieldFill.INSERT)"配合MetaObjectHandler。代码生成器在生成实体类时，直接在字段上加好这些注解，同时生成对应的自动填充处理器。这种做法把填充逻辑集中到了一起，开发人员不需要在业务代码里写任何审计字段的赋值。但它的局限在于，必须走ORM的标准增删改方法才能触发。如果项目里存在大量原生SQL或者jdbcTemplate操作，这些填充机制就会被绕过。

第三种模式是SQL拦截器统一改写。代码生成器除了生成实体和Mapper，还生成一个全局的SQL增强插件。这个插件在SQL执行前拦截PreparedStatement或者MyBatis的BoundSql，自动往insert语句里追加审计字段，往update语句的set子句里追加修改人和修改时间。这种做法的好处是覆盖面极广，无论开发人员写什么SQL，只要经过这个拦截器，审计字段就会被强制注入。代价是实现复杂度高一些，需要解析SQL语法树，处理各种复杂的子查询和批量操作场景。但一旦做成，审计字段的填充就真正做到了零死角。

实际项目中，比较务实的做法是代码生成器同时支持第二种和第三种模式，根据表的配置来决定采用哪种策略。对于核心业务表，走拦截器模式确保万无一失；对于日志类、临时类表，走实体回调模式降低性能开销。

这是自动填充最容易踩的坑。假设你有一个批量更新操作，用一条SQL更新了1000条记录的状态。按照审计要求，这1000条记录的"update_time"和"update_user"都应该更新。但如果代码生成器只是在实体层面做了自动填充，批量更新时根本不会走实体回调，审计字段就丢了。更隐蔽的问题是，有些开发人员图方便，直接用"update table set status = 1 where id in (...)"这种写法，连审计字段都没带。

代码生成器要解决这个问题，需要从两个层面下手。第一层是Mapper接口生成时，强制要求所有的update方法必须包含审计字段的更新。具体做法是生成两个版本的update方法：一个是标准版，要求传入完整实体；一个是条件版，自动在生成的SQL模板里把审计字段的更新逻辑硬编码进去。开发人员调用条件版时，不需要手动传审计字段，SQL模板会自动追加"update_time = now(), update_user = #{contextUserId}"。

第二层是代码审查层面的约束。代码生成器可以在生成Service层代码时，直接禁止在Service里写原生SQL字符串。所有对数据库的修改操作，必须通过生成的Mapper方法来完成。这样就把批量更新的路径收束到了可控的范围内。如果项目确实需要极高的批量更新性能，代码生成器应该单独生成一套经过审计增强的批量更新方法，比如"batchUpdateStatusByIds"，方法内部保证审计字段被正确填充。

审计字段里最难填的不是时间，而是当前操作人。单体应用里，从ThreadLocal或者SecurityContext里拿一下当前登录用户就行了。但在微服务架构下，一个请求可能跨多个服务，每个服务都有自己的数据库操作。如果每个服务都各自为战地去解析JWT或者调用用户中心，不仅重复代码多，而且一旦用户信息在请求链路中被修改，审计信息就会不一致。

代码生成器在这个场景下应该做的是：生成一个统一的上下文拦截器，从上游服务传递的请求头里提取操作人信息，塞进当前服务的ThreadLocal。然后所有审计字段的填充处理器都从这个ThreadLocal里取值。这个拦截器的代码完全可以由代码生成器根据项目的微服务框架自动生成，不管是Spring Cloud的Feign拦截器，还是gRPC的拦截器，原理都一样。关键在于，代码生成器生成的每个服务的审计填充逻辑，必须遵循同一套上下文传递协议，确保整个调用链路里审计信息的一致性。

还有一个容易被忽略的点是定时任务和消息消费。这类场景下没有HTTP请求，ThreadLocal里自然也没有用户信息。代码生成器需要为这类场景生成一个显式的上下文设置入口，比如在定时任务的基类里强制要求设置一个系统操作人标识，否则启动时就报错。这样就能避免大量数据变更以null操作人的形式被记录下来。

很多人以为代码生成器自动填充审计字段就是改改模板，在实体类里多加几个注解。实际上，一个真正好用的方案需要模板、配置、生成策略三方面配合。模板层面，实体类模板需要根据字段的填充时机生成不同的注解。以MyBatis-Plus为例，"createTime"字段生成"@TableField(fill = FieldFill.INSERT)"，"updateTime"字段生成"@TableField(fill = FieldFill.INSERT_UPDATE)"。同时实体类模板要去掉这些字段的setter方法，或者把setter方法标记为废弃，从API层面阻止开发人员手动赋值。

配置层面，代码生成器应该允许按表、按模块、甚至按字段粒度来定制填充策略。比如某些历史遗留表已经有自己的审计逻辑，就不需要代码生成器介入。某些表需要记录操作IP，但不需要记录设备指纹。这些差异化需求如果靠改生成后的代码来实现，后续重新生成时就会被覆盖。正确的做法是把这些配置放在代码生成器的策略文件里，每次重新生成时自动应用。

生成策略层面，需要区分新表生成和存量表迭代两种场景。新表生成时可以一步到位，把审计字段、注解、拦截器全部生成好。存量表迭代时，代码生成器要做的是增量式修改，只更新审计相关的配置，不动业务开发人员已经写的业务逻辑。这就要求代码生成器支持区域保护标记，在生成的代码中用特定注释把自动生成区域和手动编写区域隔离开。

以MyBatis-Plus为例，代码生成器生成的自动填充处理器通常长这样：

@Component
public class AuditMetaObjectHandler implements MetaObjectHandler {
    
    @Override
    public void insertFill(MetaObject metaObject) {
        this.strictInsertFill(metaObject, "createTime", Date.class, new Date());
        this.strictInsertFill(metaObject, "createUser", String.class, getCurrentUser());
        this.strictInsertFill(metaObject, "updateTime", Date.class, new Date());
        this.strictInsertFill(metaObject, "updateUser", String.class, getCurrentUser());
    }
    
    @Override
    public void updateFill(MetaObject metaObject) {
        this.strictUpdateFill(metaObject, "updateTime", Date.class, new Date());
        this.strictUpdateFill(metaObject, "updateUser", String.class, getCurrentUser());
    }
    
    private String getCurrentUser() {
        // 从统一的上下文工具类获取当前操作人
        return AuditContextHolder.getCurrentUser();
    }
}

这个处理器会在每次insert和update操作时自动触发，开发人员完全感知不到。但光有这个还不够，因为"strictUpdateFill"方法在字段已经有值的时候不会覆盖。这意味着如果开发人员手动给"updateTime"赋了一个错误的值，自动填充反而会失效。所以更严谨的做法是使用"setFieldValByName"方法强制覆盖，确保审计字段的值永远由系统统一控制。

对于JPA项目，代码生成器生成的实体基类通常会这样设计：

@MappedSuperclass
public abstract class BaseAuditEntity {
    
    @CreatedDate
    @Column(updatable = false)
    private LocalDateTime createTime;
    
    @CreatedBy
    @Column(updatable = false, length = 64)
    private String createUser;
    
    @LastModifiedDate
    private LocalDateTime updateTime;
    
    @LastModifiedBy
    @Column(length = 64)
    private String updateUser;
    
    @PrePersist
    public void prePersist() {
        this.createTime = LocalDateTime.now();
        this.updateTime = LocalDateTime.now();
        this.createUser = AuditContextHolder.getCurrentUser();
        this.updateUser = AuditContextHolder.getCurrentUser();
    }
    
    @PreUpdate
    public void preUpdate() {
        this.updateTime = LocalDateTime.now();
        this.updateUser = AuditContextHolder.getCurrentUser();
    }
}

所有业务实体继承这个基类，就能自动获得审计能力。但要注意，JPA的"@PreUpdate"回调在批量更新时同样不会触发，所以项目里如果有JPA的批量更新需求，还是得配合拦截器或者显式调用审计填充逻辑。

自动填充审计字段不只是为了合规，还能为后续的数据追溯和问题排查提供便利。但前提是这些字段上有合理的索引。很多团队建表时只在主键和业务字段上建索引，审计字段完全裸奔。等到需要查询“某个用户在过去一周修改过的所有订单”时，全表扫描直接把数据库打挂。

代码生成器在生成DDL时，应该根据审计字段的查询频率自动建议索引策略。通常"update_time"是最常被用于范围查询的字段，需要单独建索引。"create_user"和"update_user"如果经常用于过滤条件，建普通索引即可。如果是多租户场景，租户ID加"update_time"的联合索引几乎是必选项。代码生成器可以在生成建表语句时，根据一套预设规则自动添加这些索引，同时生成对应的索引分析注释，提醒DBA审核。

另一个容易被忽视的点是审计字段的保留策略。"create_time"和"create_user"理论上应该永远不变，但实际运维中可能会因为数据迁移、数据修复等操作被意外修改。代码生成器可以在生成实体类时，把"createTime"和"createUser"对应的数据库列设置为不可更新，在DDL层面就杜绝修改的可能性。对于MySQL，可以在列上使用触发器或者在应用层做约束；对于PostgreSQL，可以直接使用列级权限控制。

代码生成器自动填充审计字段这件事，再往前走一步就是自动生成审计日志。当系统能够稳定地捕获每条数据的创建人和修改人之后，很自然地就会产生数据变更历史的需求。代码生成器可以在生成Mapper时，同时生成一套基于触发器的数据变更记录逻辑，或者生成一套基于应用层AOP的变更对比逻辑。每次update操作执行前，先把旧数据查出来，与新数据做diff，然后把变更内容序列化存入审计日志表。

这套机制如果全靠开发人员手写，工作量巨大且容易出错。但代码生成器完全可以在生成Service层代码时，自动为标记了“需要审计”的表生成变更记录逻辑。开发人员只需要在配置里勾选一个选项，生成的代码就会自动处理变更捕获、差异计算、日志持久化的全部流程。这才是代码生成器在审计领域真正发挥威力的方向——不只是帮你省掉几行set代码，而是帮你建立起一套完整的数据可追溯体系。

说到底，代码生成器自动填充审计字段的价值不在于技术有多复杂，而在于它把一件所有人知道该做、但总是做不全的事情，变成了一件不用想就能做到的事情。当审计字段的维护成本降到零，开发团队的精力才能真正聚焦在业务逻辑上，数据安全也不再依赖于每个人的自觉性。选择或者自研代码生成器时，把审计字段的自动填充能力作为核心评估指标，远比看它能生成多少种花哨的页面模板要实在得多。