MyBatis Flex 与 MyBatis Plus 走的是两条不同的技术路线：Plus 依赖启动期注入 MappedStatement 加拦截器体系做扩展，功能全、生态成熟；Flex 去掉 SQL 解析与拦截器，用运行时 Provider 直接生成 SQL，换来更轻的体积和更少的执行开销。在 AI 爆款文章创作器项目里选择 Flex，主要看中它原生多表联查、零第三方依赖和复合主键支持三点。
一、两条技术路线的本质差异
1.1 SQL 生成机制
MyBatis Plus 在启动期把 MappedStatement 注入容器，分页、租户这类能力靠拦截器实现，拦截器内部会解析原始 SQL 再改写。MyBatis Flex 没有拦截器，条件由运行时 Provider 直接拼装成 SQL，分页功能内建在核心包里，整个过程不解析已有语句。这个机制差异是后续性能和体积差异的根源。
1.2 功能对比表
| 功能 | MyBatis-Plus 3.x | MyBatis-Flex |
|---|---|---|
| 分页查询 | 拦截器实现，需额外配置 | 内建在 core |
| 分页总量缓存 | 支持 | 支持 |
| 多表 join 查询 | 需要手写 XML | QueryWrapper 直接 join |
| 复合主键 / 多主键 | 不支持 | 支持 |
| 除 MyBatis 外依赖 | 有额外依赖 | 零第三方依赖 |
| 条件为 null 时 | 需要手动判断 | 自动忽略 |
| 多数据源 + Spring 事务 | 依赖其他框架或收费 | 原生支持 |
| 数据脱敏 / 字段加密 | 收费功能 | 免费 |
| 无实体类操作 | 不支持 | Db + Row |
| 生态成熟度 | 高，文档多，用户多 | 较新，社区较小 |
Plus 的护城河在生态：文档全、社区大，遇到问题基本能搜到现成方案。Flex 的优势在工程干净：无解析、无拦截器、无多余依赖，多表查询不再退回 XML。
二、性能差距从哪里来
官方基准测试给出的数据是：Flex 的查询单条、查询十条、分页查询与数据更新的速度，约为 Plus 的 5 到 10 倍。差距主要来自两点：不做 SQL 解析，省掉了拦截器里的运行时开销；生成的 SQL 只做必要处理，路径比 Plus 更短。需要说明的是，性能对比只反映单条执行路径的差异，实际业务里数据库连接池、网络、索引设计对响应时间的影响远大于框架本身，把压测放在真实表结构和数据量下做才有参考价值。
三、为什么项目里选择 MyBatis Flex
3.1 项目实际需求
文章创作器的核心表有文章表、生成任务表、提示词模板表和用量记录表，任务与文章、任务与用量天然是关联关系。Plus 的多表查询需要回到 XML 手写，而 Flex 的 QueryWrapper 直接支持 join，这层体验差异在任务追踪场景里非常明显。
- 多表关联多：文章、生成任务、用量三表联查用 QueryWrapper 直接 join，减少手写 XML；
- 局部字段更新多：任务状态、token 用量频繁回写，UpdateEntity 语义更清晰；
- 任务追踪需要审计：SQL 审计免费提供，生成任务表天然适配；
- 模块依赖要干净：零第三方依赖，网关项目多模块引入时不会带来额外包袱；
- 条件为 null 自动忽略：省掉一票空值判断代码，管线查询条件更整洁。
3.2 一个实际查询示例
// 关联查询：文章 + 生成任务 + 用量记录
QueryWrapper query = QueryWrapper.create()
.select(ARTICLE.ALL_COLUMNS, TASK.STATUS, USAGE.TOTAL_TOKENS)
.from(ARTICLE)
.leftJoin(TASK).on(ARTICLE.ID.eq(TASK.ARTICLE_ID))
.leftJoin(USAGE).on(TASK.ID.eq(USAGE.TASK_ID))
.where(ARTICLE.ID.eq(articleId));
List<Row> rows = Db.selectListByQuery(query);同样的关联查询在 Plus 里要维护一段 XML，Flex 里一段链式调用就结束。项目的查询条件大量是动态拼装的，条件为 null 自动忽略这个特性直接砍掉了条件判断代码。Db 加 Row 的组合还覆盖了无实体类场景：统计类查询不想为每张临时表建实体时，直接用 Row 承接结果，省掉一批 DTO。生成任务表的动态查询条件多，QueryWrapper 的链式条件配合自动忽略 null，让同一段代码同时服务列表页、导出和统计三个入口，不用为每个入口各写一套查询。
3.3 取舍与迁移成本
Flex 的学习成本集中在 APT 生成的 QueryColumn 常量上，需要团队花一点时间熟悉。生态薄的代价是遇到问题能查的资料有限，多数要靠官方文档和源码。迁移成本要拆成两部分看：一是 QueryColumn 的学习曲线，二是既有 XML 的迁移量。项目里关联查询本来就没有 XML，处于新建阶段，这两部分成本都接近零；如果项目已经堆了大量写好的 XML，Flex 的收益就要重新权衡。判断标准可以简单一点：新项目且多表关联多，Flex 值得试；老项目用着 Plus 顺手，生态成熟这个优势不是技术层面能衡量的，不必迁移。还有一点常被忽略：两个框架的自动填充和审计策略不同，Plus 的填充、脱敏、加密在 3.x 版本部分能力收费，Flex 这些能力免费内置，预算敏感的团队在选型表里勾选时，这一列会直接改写结论。
四、选型决策的五个步骤
- 列出项目的 CRUD 复杂度与多表关联占比，评估 XML 维护量；
- 对照复合主键、多数据源、Spring 事务这些硬需求逐项打勾；
- 在真实环境压测两个框架的查询与更新，验证性能差距是否影响业务；
- 评估团队对 APT 编译期代码生成的接受度，估算学习成本；
- 确认关键能力是免费还是付费，脱敏、加密、审计这些功能直接决定成本。
这五个步骤走完，结论自然落定：硬需求不满足直接淘汰，性能差距不明显就按团队熟悉度决定。
常见问题（FAQ）
Q1：老项目用 MyBatis-Plus 需要换 Flex 吗？
没必要，Plus 生态成熟，迁移成本大于收益。
Q2：Flex 适合什么项目？
新项目、多表关联多、在意轻量依赖的场景。
Q3：Flex 单条查询真的快 5 倍吗？
官方基准如此，实际差距受场景影响，建议压测验证。
