MyBatisPlus自动填充创建时间在GLM日志系统中应用
在构建高并发、低延迟的AI服务时，我们常常关注模型推理性能和响应速度，却容易忽视一个看似“基础”却极为关键的问题：日志数据的时间准确性。尤其是在部署像GLM-4.6V-Flash-WEB这类面向Web场景优化的多模态视觉大模型时，每一次图像问答、内容理解请求的背后，都应有一条完整、可信的日志记录作为追溯依据。
而现实中，很多团队的日志表里create_time字段要么为空，要么依赖业务代码手动设置——这不仅增加了开发负担，更埋下了数据不一致的风险。试想一下：当运维需要排查某次异常调用时，却发现日志时间是客户端传来的、甚至被篡改过的值，那这条日志的价值还剩多少？
正是在这种背景下，我们将目光投向了 MyBatisPlus 的一项“低调但实用”的功能：字段自动填充（Auto-Fill）。通过它，我们可以让数据库层自动为每条日志补上准确的创建时间，彻底摆脱“忘记 setCreateTime()”的尴尬。
为什么选择 MyBatisPlus 自动填充？
MyBatisPlus 不仅简化了 CRUD 操作，其对审计字段的支持也相当成熟。相比传统方式中在每个 service 方法里写entity.setCreateTime(LocalDateTime.now())，自动填充机制将这一逻辑统一收口到框架层面，实现了真正的“一次配置，处处生效”。
它的核心在于MetaObjectHandler接口。每当执行插入或更新操作时，MyBatisPlus 会拦截实体对象的元数据，并根据注解规则判断哪些字段需要自动赋值。整个过程对业务代码完全透明，真正做到了非侵入式增强。
比如，在我们的 GLM 日志系统中，只需要做两件事：
- 在实体类中标记需要填充的字段；
- 实现一个全局处理器来定义填充逻辑。
之后，无论是在正常流程还是异步任务中调用insert()，createTime都会被自动注入当前服务器时间，无需任何额外干预。
如何实现？从代码到结构一体化设计
先来看关键组件的实现。
自定义元对象处理器
@Component public class MyMetaObjectHandler implements MetaObjectHandler { @Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, "createTime", LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, "createUser", String.class, "system"); } @Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } }这里使用的是strictInsertFill而非旧式的setFieldValByName，原因很简单：类型安全。如果字段名拼错或者类型不匹配，编译期就能发现问题，而不是等到运行时报空指针或静默失败。
同时，我们也将createUser设为固定值"system"，表明这些日志是由系统自动生成的，而非具体用户操作，便于后续权限与行为分析。
实体类定义：用注解声明意图
@Data @TableName("t_log_record") public class LogRecord { @TableId(type = IdType.AUTO) private Long id; private String requestId; private String inputText; private String imageUrl; private String result; @TableField(fill = FieldFill.INSERT) private LocalDateTime createTime; @TableField(fill = FieldFill.INSERT_UPDATE) private LocalDateTime updateTime; @TableField(fill = FieldFill.INSERT) private String createUser; }注意@TableField(fill = ...)的语义控制：
-createTime只在插入时填充，一旦写入便不再变动；
-updateTime则在插入和更新时都会刷新，确保最后修改时间始终准确；
- 所有带fill标记的字段，在 SQL 构造阶段由框架动态加入 SET 子句，原生字段仍可被业务逻辑覆盖（如有必要）。
融入 GLM-4.6V-Flash-WEB 的服务链路
GLM-4.6V-Flash-WEB 是智谱推出的一款专为 Web 场景优化的轻量级多模态模型，主打百毫秒级响应、单卡可部署，非常适合嵌入实时交互系统。其典型调用链如下：
[用户] → [前端/API网关] → [Spring Boot服务] → [本地GLM服务] → [返回结果] ↓ [写入日志表 t_log_record]在这个流程中，Spring Boot 层承担着协调角色：接收请求、转发给模型服务、封装结果，并最终落盘一条完整的调用日志。
假设我们没有启用自动填充，那么开发者必须记得在每次插入前显式设置时间：
logRecord.setCreateTime(LocalDateTime.now()); // 容易遗漏！ logRecordMapper.insert(logRecord);一旦遇到异常捕获、提前返回或多分支逻辑，这个调用很容易被跳过。而启用 MyBatisPlus 自动填充后，哪怕你忘了设时间，框架也会帮你补上，极大提升了数据完整性保障能力。
数据库设计与双重防护策略
虽然框架能自动填充，但我们依然建议在数据库层面增加一层兜底保护。例如，在 MySQL 中为create_time字段添加默认值约束：
ALTER TABLE t_log_record MODIFY COLUMN create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间';这样一来，即使 ORM 框架因配置失效未能填充，数据库也能自动补上当前时间。这种“双保险”机制特别适合用于审计级数据表。
当然，理想情况下应优先依赖应用层统一处理，因为：
- 数据库默认值无法区分“真实插入时间”与“补救性填充”；
- 分布式环境下，数据库时间可能与应用服务器存在偏差；
- 应用层可以更灵活地支持时区标准化（如统一使用 UTC+8）；
因此，推荐以 MyBatisPlus 填充为主，数据库默认值为辅。
实际收益：不只是省了几行代码
这项改进带来的价值远超“少写一行 setCreateTime()”这么简单。我们来看几个真实场景中的受益点：
1. 提升日志可信度，满足合规要求
在金融、医疗或政务类 AI 应用中，操作留痕是基本合规要求。若日志时间由前端传递或人工设置，存在被伪造的风险。而由服务端在持久化瞬间生成的时间戳，则具有更强的防篡改属性，有助于通过 GDPR、网络安全法等审计。
2. 统一团队编码规范，降低协作成本
在一个多人维护的服务模块中，不同成员对“是否要设时间”的认知可能不一致。有人认为“DAO 会自动处理”，有人则坚持“自己设才保险”。这种模糊地带极易引发 Bug。引入自动填充后，规则明确、行为一致，新人接入也无需反复提醒。
3. 支持精准性能分析与调用追踪
当我们想统计“过去一小时平均推理耗时”时，依赖的是日志表中的create_time与请求头中的timestamp之差。如果create_time存在缺失或漂移，计算结果就会失真。而自动填充保证了每一行数据都有可靠的时间基准，使得监控报表更具参考意义。
4. 兼容批量插入与复杂事务场景
MyBatisPlus 从 3.4.0 版本开始已全面支持saveBatch()中的自动填充。这意味着即便你在批处理任务中一次性写入上千条日志，每一条的createTime依然会被正确赋值，无需手动遍历设置。
此外，在分布式事务或 AOP 切面中记录日志时，也能无缝继承该机制，避免因上下文丢失导致时间字段为空。
注意事项与最佳实践
尽管自动填充功能强大，但在实际落地过程中仍有几点需要注意：
✅ 使用LocalDateTime替代Date
Java 8 引入的LocalDateTime更清晰地表达了“无时区的时间点”概念，避免了Date类常见的时区混淆问题。配合数据库的DATETIME类型，能够确保时间存储的一致性。
✅ 确保服务器时间同步（NTP）
在多节点部署环境下，若各机器系统时间不同步，即使自动填充也无法保证日志时间的全局有序性。建议开启 NTP 时间同步服务，确保所有实例时间误差控制在毫秒级以内。
✅ 合理命名字段并保持映射一致
建议统一采用驼峰命名（如createTime）并在application.yml中配置 MyBatisPlus 的下划线转驼峰：
mybatis-plus: configuration: map-underscore-to-camel-case: true这样即使数据库字段为create_time，也能自动映射成功，减少手动指定@TableField(value = "...")的麻烦。
✅ 编写单元测试验证填充逻辑
不要假设“配置完就一定生效”。建议编写简单的测试用例验证自动填充是否起作用：
@Test void should_auto_fill_create_time_on_insert() { LogRecord record = new LogRecord(); record.setRequestId("test-123"); logRecordMapper.insert(record); assertThat(record.getCreateTime()).isNotNull(); assertThat(record.getCreateUser()).isEqualTo("system"); }这类测试虽小，却能在 CI/CD 流程中及时发现配置遗漏或版本兼容问题。
总结：让基础设施做它擅长的事
在 AI 工程化实践中，我们往往把注意力集中在模型精度、推理速度、GPU 利用率等“高光指标”上，却忽略了数据治理这一底层支柱。事实上，没有高质量的日志，就没有可靠的可观测性；没有可观测性，再快的模型也只是黑盒。
通过将 MyBatisPlus 的自动填充机制应用于 GLM-4.6V-Flash-WEB 的日志系统，我们实现了一个微小但重要的跃迁：把时间字段的管理权交给框架，让开发者专注于业务逻辑本身。
这不仅是代码上的减负，更是工程思维的进步——相信基础设施的能力，用约定代替命令，用自动化替代重复劳动。这样的设计思路，正推动着越来越多的 AI 服务平台走向稳定、可维护、可持续演进的轨道。
