半夜突发故障！MyBatis-Plus“理论上不可能”的坑，我们踩了……

📌 一句话摘要

本文基于转转技术团队的真实生产事故，系统梳理了 MyBatis-Plus 在分布式、高并发环境下最容易暴雷的六大陷阱，并给出根因分析与实测可行的解决方案。

📝 详细摘要

文章由转转技术团队的一线开发者撰写，基于多年生产环境使用 MyBatis-Plus 的真实踩坑经历，系统总结了六大高频陷阱：雪花算法 ID 生成重复（容器/K8s 环境 workerId 冲突、时钟回拨）、批量插入乱序（JDBC 驱动与数据库优化器重排）、枚举字段存储异常（默认使用 name() 而非 code）、驼峰转换错位（连续大写字母映射失败）、批量操作时自动填充失效（跳过 MetaObjectHandler）、JSON 数据写入丢失或格式异常（缺少类型处理器）。每个问题都从现象、原理到解决方案层层拆解，提供了可复用的代码示例与配置建议，并最终给出三条生产环境启示：默认配置靠不住、机制理解少不了、方案要服务于环境。

💡 主要观点

- 雪花算法 ID 重复的根因是容器/K8s 环境下 workerId 自动分配冲突与时钟回拨。 MyBatis-Plus 默认依赖 MAC 地址计算 workerId，但 Docker 容器 MAC 地址前缀固定、K8s Pod 虚拟 MAC 可能重复，实例数超过 32 即产生冲突；时钟回拨也会导致相同时间戳下 ID 重复。

批量插入乱序源于 JDBC 驱动与数据库优化器对 SQL 的重排序。 默认 BATCH 模式在开启 rewriteBatchedStatements 后，驱动会将同表 SQL 合并；数据库优化器也会将同表操作集中执行，导致父子表插入顺序错乱，外键约束失败。

枚举字段默认存储枚举名称而非 code 值，需使用 @EnumValue 注解显式指定。 MyBatis 默认的 EnumTypeHandler 调用枚举的 name() 方法，将 'PENDING' 而非 1 存入数据库；通过 @EnumValue 标记 code 字段可解决。

驼峰转换对连续大写字母（如 buyerUID、XMLData）映射失败，需显式指定 @TableField。 默认转换算法将连续大写视为独立单词，buyerUID 被转为 buyer_u_i_d；推荐统一命名规范或使用 @TableField 明确映射。

批量操作时自动填充失效，因为 saveBatch 跳过了 MetaObjectHandler 的调用。 MyBatis-Plus 的自动填充仅在单条 insert/update 时触发；批量操作直接使用 JDBC 批处理，需手动填充或自定义批量方法。

💬 文章金句

- 框架默认值是给理想环境准备的，到了生产就得重新审视。

• 只有搞清楚框架怎么运转，才能提前发现风险；真出事时，也能快速定位。知其然而且要知其所以然。
• 你在什么环境里跑，就得配什么策略。容器、K8s、云原生都在挑战旧有假设。没有银弹，只有适配。

📊 文章信息

AI 初评：86

来源：dbaplus社群

作者：dbaplus社群

分类：软件编程

语言：中文

阅读时间：27 分钟

字数：6521

标签： 后端开发, MyBatis-Plus, Java, 数据库, 生产事故

阅读完整文章