15 个维度剖析 JPA、MyBatis-Plus 与 Xbatis不吹不黑一针见血下面从 15 个维度对 JPA、MyBatis-Plus 和 Xbatis 进行深入分析。设计哲学在设计哲学方面JPA 是全自动 ORM秉持“你操作对象SQL 我来生成”的理念属于“黑盒”模式方便到让使用者忘记 SQL 存在但也不清楚它到底发了什么 SQLMyBatis-Plus 是增强工具即“MyBatis 的油门助力但方向盘还是你的”为“半自动”模式能帮使用者省掉模板代码不过复杂 SQL 仍需自己写 XMLXbatis 是重度 ORM 链式 DSL主张“写代码像写 SQL但不用写 SQL”是“透明”模式其 API 自带 SQL 语义使用者能看到每一步在干什么却不需要手写字符串。结论是JPA 想让使用者忘了数据库MP 让使用者少写模板 SQLXbatis 让使用者用 Java 写出 SQL 的表达力。核心 API 风格JPA 的核心 API 风格中简单查询靠方法命名约定猜名字复杂查询靠 JPQL 字符串动态查询靠 Criteria API但 Criteria API 冗长。MyBatis-Plus 的 Wrapper 是参数不是方法体API 分裂感强烈遇到多表查询则需回 XML。Xbatis 采用链式 DSL方法体即查询一气呵成。结论是JPA 的方法名魔法在小项目里适用大项目里是灾难MP 的 Wrapper 是二等公民割裂感强Xbatis 的 Chain 是一等公民连贯到底。单表 CRUD谁更省事在单表 CRUD 操作中按 ID 查JPA 用 repo.findById(id)MyBatis-Plus 用 mapper.selectById(id)Xbatis 用 dao.getById(id)按 ID 查部分列JPA 需 Query 投影MyBatis-Plus 需手写 selectXbatis 可用 dao.getById(id, User::getName, User::getAge)按 ID 查单列值JPA 和 MyBatis-Plus 都无法实现Xbatis 可用 dao.getValueById(id, User::getName)批量插入JPA 用 repo.saveAll(list)MyBatis-Plus 用 mapper.insertBatch(list)Xbatis 用 dao.insertChain().insert(list).execute()部分字段更新JPA 需先查再设再存MyBatis-Plus 用 mapper.updateById(entity) 全字段Xbatis 用 dao.partialUpdate(model) 精准修改重复插入策略JPA 和 MyBatis-Plus 都没有Xbatis 内置 ON DUPLICATE KEY / ON CONFLICTRETURNING 子句JPA 和 MyBatis-Plus 都不支持Xbatis 可用 updateChain().returning(...) 更新后直接返回结果。亮点是Xbatis 的 partialUpdate 是三者中唯一做到“先查出来只改我关心的字段”的JPA 需要 DynamicUpdateMP 只能用 LambdaUpdateWrapper 逐字段 set。多表联查 ---- 撕开底裤的一刀多表联查是三者的分水岭。JPA 靠 OneToMany/ManyToOne 隐式关联简单场景下很爽但容易出现 N 1 问题比如某天发现一个列表页发了 500 条 SQL可能是因为忘了写 EntityGraph。MyBatis-Plus 官方态度是多表查询请回 XML没有 join API 和联表 DSLWrapper 只负责 WHERE 条件这意味着还是要写手写 SQL在这里 MP 等于裸 MyBatis。Xbatis 有原生 join DSL还可用 Fetch 先查 A 再带出 B。结论是JPA 隐式关联是双刃剑简单场景爽、复杂场景炸MP 在多表这件事上直接放弃治疗Xbatis 是唯一把多表查询当一等公民对待的。动态条件查询在动态条件查询场景中搜索表单忽略 null/空串/trimJPA 的 Specification 冗长MyBatis-Plus 的 Wrapper 需手动判空Xbatis 用 forSearch(true) 一键搞定精确条件按值决定是否忽略JPA 同 SpecificationMyBatis-Plus 用 wrapper.eq(cond, field, val)Xbatis 用 .eq(field, val, Objects::nonNull) predicate 重载OR 条件成组JPA 用 cb.or(...) 嵌套地狱MyBatis-Plus 用 wrapper.and(w - w.or(...))Xbatis 用 .nested(chain - chain.or(...))对象转条件JPA 和 MyBatis-Plus 都无法实现Xbatis 用 ConditionTarget QO.where() 注解驱动对象转排序JPA 和 MyBatis-Plus 都做不到Xbatis 用 OrderByTarget 自动转换。Xbatis 的 QO查询对象是杀手级差异它能让 Service 层干净。结论是JPA 的 Specification 写一次就想辞职MP 的 Wrapper 在 Service 层散落一堆 if 判空Xbatis 的 QO 把条件和查询分离是三者中架构最干净的。分页能力在分页能力方面基础分页JPA 用 PageableMyBatis-Plus 用 PageT 插件Xbatis 用 Pager 内建自动 COUNT 优化JPA 无法实现MyBatis-Plus 是基础优化Xbatis 则是激进优化能自动去掉无用 LEFT JOIN、ORDER BYJOIN 分页优化JPA 和 MyBatis-Plus 都无法实现Xbatis 能自动识别 1 对多支持 rightJoin 切换子查询分页JPA 和 MyBatis-Plus 都不支持Xbatis 原生支持无 SQL 解析分页JPA 做不到MyBatis-Plus 依赖 JsqlParserXbatis 更轻量。结论是JPA 的分页靠 Pageable 传参SQL 优化靠祈祷。MP 靠 JsqlParser 解析。Xbatis 的分页优化是内置的、无解析开销的而且对 JOIN 场景做了专项处理。VO 映射 / 结果处理在 VO 映射和结果处理能力上自动列选择JPA 需 DTO 投影MyBatis-Plus 无法实现Xbatis 用 select(VO.class) 自动推导JOIN 结果自动映射JPA 和 MyBatis-Plus 都不行Xbatis 用 returnType(VO.class) 一键完成多层嵌套结果JPA 和 MyBatis-Plus 都不支持Xbatis 用 NestedResultEntity枚举名称注入JPA 和 MyBatis-Plus 都做不到Xbatis 用 PutEnumValueFetch 二次查询JPA 可用 EntityGraphMyBatis-Plus 无法实现Xbatis 原生支持 Fetch。直观对比联表返回 VOJPA 没有标准优雅方案MP 需回退 XML 手写 ResultMapXbatis 则很简单。结论是VO 映射是 JPA 的阿喀琉斯之踵是 MP 的不治之症是 Xbatis 的舒适区。Mapper 模式Mapper 模式方面每实体一个 Mapper/RepositoryJPA、MyBatis-Plus 都可以Xbatis 可选单 Mapper 模式JPA 和 MyBatis-Plus 都不行Xbatis 可以一个 BasicMapper 就能操作所有实体。单 Mapper 的意义在于当有 200 张表时MP 需要 200 个 Mapper 接口 200 个 XML 文件而 Xbatis 的单 Mapper 模式下一个 XbatisMapper extends BasicMapper 通吃所有实体项目越大优势越明显。结论是JPA 的 Repository 和 MP 的 Mapper 在项目膨胀时都是文件爆炸。Xbatis 的单 Mapper 是工业化项目的真实刚需。逻辑删除 / 多租户 / 乐观锁三个框架都支持逻辑删除、多租户和乐观锁但实现质量差别很大。逻辑删除JPA 用 SQLDelete Where Hibernate 扩展MyBatis-Plus 用 TableLogicXbatis 用 LogicDelete LogicDeleteTime支持除 flag 外任意字段 set多租户JPA 需自己实现拦截器MyBatis-Plus 用插件需配置Xbatis 用 TenantId 注解驱动透明注入乐观锁三者都用 Version动态值/审计字段JPA 用 CreatedDate 等 Spring Data 注解MyBatis-Plus 用 TableField(fill ...)Xbatis 用 TableField(defaultValue {NOW}, update false) 模板语法更强。Xbatis 逻辑删除的独特性在于不仅支持 deleted 1还支持删除时自动填入删除时间、删除人MP 只能设 flag。结论是三个都“有”但 JPA 的多租户需要自己搞MP 的逻辑删除偏简单Xbatis 的注解驱动更彻底。SQL 控制力 XML 回退在 SQL 控制力和 XML 回退方面手写 SQLJPA 用 Query JPQL / NativeMyBatis-Plus 用 XML / SelectXbatis 用 SQL 模板 原生 SQLSQL 模板局部复杂表达式JPA 和 MyBatis-Plus 都无法实现Xbatis 用 Methods.tpl() / Methods.fTpl()不同数据库不同 SQLJPA 和 MyBatis-Plus 都做不到Xbatis 用 dbAdapt(selector - ...) 局部差异化XML 是否必须JPA 基本不用MyBatis-Plus 复杂场景必须用Xbatis 是最后手段90% 需求不需要。结论是JPA 用 JPQL 是另一种语言。MP 复杂查询必须 XML。Xbatis 让使用者绝大部分时候不需要 XML即使需要也能用模板在 DSL 中局部嵌入而非整个查询回退。跨数据库兼容跨数据库兼容能力上内置数据库函数JPA 靠方言MyBatis-Plus 无法实现Xbatis 有 13 种数据库通用函数不同数据库不同 ID 自增策略JPA 和 MyBatis-Plus 都不行Xbatis 可以分页方言JPA 用 Hibernate 方言MyBatis-Plus 是基础Xbatis 深度适配代码零改动迁移JPA 理论可行实际坑多MyBatis-Plus 无法实现Xbatis 可以。结论是JPA 靠 Hibernate 方言层但遇到复杂函数就不行。MP 基本不考虑跨库。Xbatis 内置了大量跨数据库函数如 Methods.concat()、Methods.dateFormat()一套代码跑多种数据库不折腾。注解体系完整度注解体系完整度方面实体映射JPA 用 Entity Table Id ColumnMyBatis-Plus 用 TableName TableId TableFieldXbatis 用 Table TableId TableField逻辑删除JPA 靠 Hibernate 扩展MyBatis-Plus 用 TableLogicXbatis 用 LogicDelete LogicDeleteTime多租户JPA 和 MyBatis-Plus 都无法实现Xbatis 用 TenantId乐观锁三者都用 Version结果映射JPA 和 MyBatis-Plus 都不行Xbatis 用 ResultEntity NestedResultEntity ResultCalcField条件映射JPA 和 MyBatis-Plus 都做不到Xbatis 用 ConditionTarget Condition Conditions ConditionGroupFetch 抓取JPA 用 OneToMany(fetch ...)MyBatis-Plus 无法实现Xbatis 用 Fetch枚举值注入JPA 和 MyBatis-Plus 都不支持Xbatis 用 PutEnumValuePOJO 安全检查JPA 和 MyBatis-Plus 都没有Xbatis 启动时检查映射缺口排序对象JPA 和 MyBatis-Plus 都无法实现Xbatis 用 OrderByTarget。结论是JPA 只有 ORM 基础注解MP 只有单表注解。Xbatis 的注解体系是唯一覆盖“字段 - 条件 - 结果 - 排序 - 安全检查”全链路的。代码生成器代码生成器能力上Entity 生成JPA 用 IDE / 手动MyBatis-Plus 和 Xbatis 都可以Mapper/DAO 生成JPA 不需要Repository 足够MyBatis-Plus 和 Xbatis 都可以可视化配置JPA 无法实现MyBatis-Plus 可以Xbatis 较弱自定义模板JPA 做不到MyBatis-Plus 可用 Velocity/Freemarker/EnjoyXbatis 可以。结论是MP 的代码生成器是它的招牌成熟度最高。Xbatis 有但不如 MP 丰富。如果代码生成器是核心选型依据MP 赢。生态与社区生态与社区方面社区规模JPA 是全球标准MyBatis-Plus 是国内霸主Xbatis 是新兴GitHub 132 Stars文档质量JPA 是四星MyBatis-Plus 是五星Xbatis 是四星中文详尽问题解决速度JPA 可 Google 随便搜MyBatis-Plus 在 CSDN/掘金 有海量资源Xbatis 社区尚小Spring Boot 集成JPA 是原生MyBatis-Plus 和 Xbatis 的 Starter 都齐全Solon 集成JPA 无法实现MyBatis-Plus3.5.9 可以Xbatis 有原生 Solon StarterGraalVM NativeJPA 和 Xbatis 都不支持MyBatis-Plus 3.5.17 支持。结论是JPA 有 Java EE 标准背书MP 有用户基数碾压Xbatis 的生态还需要时间。学习曲线学习曲线方面JPA 入门门槛低但精通门槛极高典型痛点是持久化上下文、懒加载、N 1、缓存机制使用者以为懂了上线就可能出问题MyBatis-Plus 入门门槛低精通门槛中典型痛点是 Wrapper 写复杂条件时嵌套地狱多表必须回 XMLXbatis 入门门槛中精通门槛中概念稍多Chain/QO/Model/VO但一旦理解就一通百通。结论是JPA 是“入门即巅峰深入即地狱”。MP 是“一马平川直到需要 JOIN”。Xbatis 是“前 3 天消化概念后面全是爽的”。最终裁决选谁如果项目以单表 CRUD 为主团队想快速出活应选 MyBatis-Plus其代码生成器实用社区方案多如果项目是标准的企业级应用有大量关联查询应选 Xbatis其 JOIN 不用 XMLVO 自动映射分页自动优化如果追求 Java EE 标准、DDD、纯面向对象应选 JPA但要准备好为 N 1 和复杂查询付出额外代价如果项目有 100 张表复杂报表还要跨数据库应选 Xbatis其单 Mapper 原生 JOIN SQL 模板优势明显如果已经有成熟的 MP 项目不想重构应继续使用 MP如果从 Spring Boot 迁移到 Solon应选 Xbatis其 Solon 原生集成MP 的 Solon 支持是后补的。一句话暴击JPA你以为它在帮你其实它在瞒你。N 1 的债迟早要还。MyBatis-Plus单表的神多表的狗。JOIN 的那一刻它把你丢回给了 MyBatis。Xbatis把 MyBatis 真正 ORM 化的框架。JOIN、VO、分页、多租户 ---- API 到哪能力到哪不需要 XML 救场。
15 个维度剖析 JPA、MyBatis-Plus 与 Xbatis不吹不黑一针见血下面从 15 个维度对 JPA、MyBatis-Plus 和 Xbatis 进行深入分析。设计哲学在设计哲学方面JPA 是全自动 ORM秉持“你操作对象SQL 我来生成”的理念属于“黑盒”模式方便到让使用者忘记 SQL 存在但也不清楚它到底发了什么 SQLMyBatis-Plus 是增强工具即“MyBatis 的油门助力但方向盘还是你的”为“半自动”模式能帮使用者省掉模板代码不过复杂 SQL 仍需自己写 XMLXbatis 是重度 ORM 链式 DSL主张“写代码像写 SQL但不用写 SQL”是“透明”模式其 API 自带 SQL 语义使用者能看到每一步在干什么却不需要手写字符串。结论是JPA 想让使用者忘了数据库MP 让使用者少写模板 SQLXbatis 让使用者用 Java 写出 SQL 的表达力。核心 API 风格JPA 的核心 API 风格中简单查询靠方法命名约定猜名字复杂查询靠 JPQL 字符串动态查询靠 Criteria API但 Criteria API 冗长。MyBatis-Plus 的 Wrapper 是参数不是方法体API 分裂感强烈遇到多表查询则需回 XML。Xbatis 采用链式 DSL方法体即查询一气呵成。结论是JPA 的方法名魔法在小项目里适用大项目里是灾难MP 的 Wrapper 是二等公民割裂感强Xbatis 的 Chain 是一等公民连贯到底。单表 CRUD谁更省事在单表 CRUD 操作中按 ID 查JPA 用 repo.findById(id)MyBatis-Plus 用 mapper.selectById(id)Xbatis 用 dao.getById(id)按 ID 查部分列JPA 需 Query 投影MyBatis-Plus 需手写 selectXbatis 可用 dao.getById(id, User::getName, User::getAge)按 ID 查单列值JPA 和 MyBatis-Plus 都无法实现Xbatis 可用 dao.getValueById(id, User::getName)批量插入JPA 用 repo.saveAll(list)MyBatis-Plus 用 mapper.insertBatch(list)Xbatis 用 dao.insertChain().insert(list).execute()部分字段更新JPA 需先查再设再存MyBatis-Plus 用 mapper.updateById(entity) 全字段Xbatis 用 dao.partialUpdate(model) 精准修改重复插入策略JPA 和 MyBatis-Plus 都没有Xbatis 内置 ON DUPLICATE KEY / ON CONFLICTRETURNING 子句JPA 和 MyBatis-Plus 都不支持Xbatis 可用 updateChain().returning(...) 更新后直接返回结果。亮点是Xbatis 的 partialUpdate 是三者中唯一做到“先查出来只改我关心的字段”的JPA 需要 DynamicUpdateMP 只能用 LambdaUpdateWrapper 逐字段 set。多表联查 ---- 撕开底裤的一刀多表联查是三者的分水岭。JPA 靠 OneToMany/ManyToOne 隐式关联简单场景下很爽但容易出现 N 1 问题比如某天发现一个列表页发了 500 条 SQL可能是因为忘了写 EntityGraph。MyBatis-Plus 官方态度是多表查询请回 XML没有 join API 和联表 DSLWrapper 只负责 WHERE 条件这意味着还是要写手写 SQL在这里 MP 等于裸 MyBatis。Xbatis 有原生 join DSL还可用 Fetch 先查 A 再带出 B。结论是JPA 隐式关联是双刃剑简单场景爽、复杂场景炸MP 在多表这件事上直接放弃治疗Xbatis 是唯一把多表查询当一等公民对待的。动态条件查询在动态条件查询场景中搜索表单忽略 null/空串/trimJPA 的 Specification 冗长MyBatis-Plus 的 Wrapper 需手动判空Xbatis 用 forSearch(true) 一键搞定精确条件按值决定是否忽略JPA 同 SpecificationMyBatis-Plus 用 wrapper.eq(cond, field, val)Xbatis 用 .eq(field, val, Objects::nonNull) predicate 重载OR 条件成组JPA 用 cb.or(...) 嵌套地狱MyBatis-Plus 用 wrapper.and(w - w.or(...))Xbatis 用 .nested(chain - chain.or(...))对象转条件JPA 和 MyBatis-Plus 都无法实现Xbatis 用 ConditionTarget QO.where() 注解驱动对象转排序JPA 和 MyBatis-Plus 都做不到Xbatis 用 OrderByTarget 自动转换。Xbatis 的 QO查询对象是杀手级差异它能让 Service 层干净。结论是JPA 的 Specification 写一次就想辞职MP 的 Wrapper 在 Service 层散落一堆 if 判空Xbatis 的 QO 把条件和查询分离是三者中架构最干净的。分页能力在分页能力方面基础分页JPA 用 PageableMyBatis-Plus 用 PageT 插件Xbatis 用 Pager 内建自动 COUNT 优化JPA 无法实现MyBatis-Plus 是基础优化Xbatis 则是激进优化能自动去掉无用 LEFT JOIN、ORDER BYJOIN 分页优化JPA 和 MyBatis-Plus 都无法实现Xbatis 能自动识别 1 对多支持 rightJoin 切换子查询分页JPA 和 MyBatis-Plus 都不支持Xbatis 原生支持无 SQL 解析分页JPA 做不到MyBatis-Plus 依赖 JsqlParserXbatis 更轻量。结论是JPA 的分页靠 Pageable 传参SQL 优化靠祈祷。MP 靠 JsqlParser 解析。Xbatis 的分页优化是内置的、无解析开销的而且对 JOIN 场景做了专项处理。VO 映射 / 结果处理在 VO 映射和结果处理能力上自动列选择JPA 需 DTO 投影MyBatis-Plus 无法实现Xbatis 用 select(VO.class) 自动推导JOIN 结果自动映射JPA 和 MyBatis-Plus 都不行Xbatis 用 returnType(VO.class) 一键完成多层嵌套结果JPA 和 MyBatis-Plus 都不支持Xbatis 用 NestedResultEntity枚举名称注入JPA 和 MyBatis-Plus 都做不到Xbatis 用 PutEnumValueFetch 二次查询JPA 可用 EntityGraphMyBatis-Plus 无法实现Xbatis 原生支持 Fetch。直观对比联表返回 VOJPA 没有标准优雅方案MP 需回退 XML 手写 ResultMapXbatis 则很简单。结论是VO 映射是 JPA 的阿喀琉斯之踵是 MP 的不治之症是 Xbatis 的舒适区。Mapper 模式Mapper 模式方面每实体一个 Mapper/RepositoryJPA、MyBatis-Plus 都可以Xbatis 可选单 Mapper 模式JPA 和 MyBatis-Plus 都不行Xbatis 可以一个 BasicMapper 就能操作所有实体。单 Mapper 的意义在于当有 200 张表时MP 需要 200 个 Mapper 接口 200 个 XML 文件而 Xbatis 的单 Mapper 模式下一个 XbatisMapper extends BasicMapper 通吃所有实体项目越大优势越明显。结论是JPA 的 Repository 和 MP 的 Mapper 在项目膨胀时都是文件爆炸。Xbatis 的单 Mapper 是工业化项目的真实刚需。逻辑删除 / 多租户 / 乐观锁三个框架都支持逻辑删除、多租户和乐观锁但实现质量差别很大。逻辑删除JPA 用 SQLDelete Where Hibernate 扩展MyBatis-Plus 用 TableLogicXbatis 用 LogicDelete LogicDeleteTime支持除 flag 外任意字段 set多租户JPA 需自己实现拦截器MyBatis-Plus 用插件需配置Xbatis 用 TenantId 注解驱动透明注入乐观锁三者都用 Version动态值/审计字段JPA 用 CreatedDate 等 Spring Data 注解MyBatis-Plus 用 TableField(fill ...)Xbatis 用 TableField(defaultValue {NOW}, update false) 模板语法更强。Xbatis 逻辑删除的独特性在于不仅支持 deleted 1还支持删除时自动填入删除时间、删除人MP 只能设 flag。结论是三个都“有”但 JPA 的多租户需要自己搞MP 的逻辑删除偏简单Xbatis 的注解驱动更彻底。SQL 控制力 XML 回退在 SQL 控制力和 XML 回退方面手写 SQLJPA 用 Query JPQL / NativeMyBatis-Plus 用 XML / SelectXbatis 用 SQL 模板 原生 SQLSQL 模板局部复杂表达式JPA 和 MyBatis-Plus 都无法实现Xbatis 用 Methods.tpl() / Methods.fTpl()不同数据库不同 SQLJPA 和 MyBatis-Plus 都做不到Xbatis 用 dbAdapt(selector - ...) 局部差异化XML 是否必须JPA 基本不用MyBatis-Plus 复杂场景必须用Xbatis 是最后手段90% 需求不需要。结论是JPA 用 JPQL 是另一种语言。MP 复杂查询必须 XML。Xbatis 让使用者绝大部分时候不需要 XML即使需要也能用模板在 DSL 中局部嵌入而非整个查询回退。跨数据库兼容跨数据库兼容能力上内置数据库函数JPA 靠方言MyBatis-Plus 无法实现Xbatis 有 13 种数据库通用函数不同数据库不同 ID 自增策略JPA 和 MyBatis-Plus 都不行Xbatis 可以分页方言JPA 用 Hibernate 方言MyBatis-Plus 是基础Xbatis 深度适配代码零改动迁移JPA 理论可行实际坑多MyBatis-Plus 无法实现Xbatis 可以。结论是JPA 靠 Hibernate 方言层但遇到复杂函数就不行。MP 基本不考虑跨库。Xbatis 内置了大量跨数据库函数如 Methods.concat()、Methods.dateFormat()一套代码跑多种数据库不折腾。注解体系完整度注解体系完整度方面实体映射JPA 用 Entity Table Id ColumnMyBatis-Plus 用 TableName TableId TableFieldXbatis 用 Table TableId TableField逻辑删除JPA 靠 Hibernate 扩展MyBatis-Plus 用 TableLogicXbatis 用 LogicDelete LogicDeleteTime多租户JPA 和 MyBatis-Plus 都无法实现Xbatis 用 TenantId乐观锁三者都用 Version结果映射JPA 和 MyBatis-Plus 都不行Xbatis 用 ResultEntity NestedResultEntity ResultCalcField条件映射JPA 和 MyBatis-Plus 都做不到Xbatis 用 ConditionTarget Condition Conditions ConditionGroupFetch 抓取JPA 用 OneToMany(fetch ...)MyBatis-Plus 无法实现Xbatis 用 Fetch枚举值注入JPA 和 MyBatis-Plus 都不支持Xbatis 用 PutEnumValuePOJO 安全检查JPA 和 MyBatis-Plus 都没有Xbatis 启动时检查映射缺口排序对象JPA 和 MyBatis-Plus 都无法实现Xbatis 用 OrderByTarget。结论是JPA 只有 ORM 基础注解MP 只有单表注解。Xbatis 的注解体系是唯一覆盖“字段 - 条件 - 结果 - 排序 - 安全检查”全链路的。代码生成器代码生成器能力上Entity 生成JPA 用 IDE / 手动MyBatis-Plus 和 Xbatis 都可以Mapper/DAO 生成JPA 不需要Repository 足够MyBatis-Plus 和 Xbatis 都可以可视化配置JPA 无法实现MyBatis-Plus 可以Xbatis 较弱自定义模板JPA 做不到MyBatis-Plus 可用 Velocity/Freemarker/EnjoyXbatis 可以。结论是MP 的代码生成器是它的招牌成熟度最高。Xbatis 有但不如 MP 丰富。如果代码生成器是核心选型依据MP 赢。生态与社区生态与社区方面社区规模JPA 是全球标准MyBatis-Plus 是国内霸主Xbatis 是新兴GitHub 132 Stars文档质量JPA 是四星MyBatis-Plus 是五星Xbatis 是四星中文详尽问题解决速度JPA 可 Google 随便搜MyBatis-Plus 在 CSDN/掘金 有海量资源Xbatis 社区尚小Spring Boot 集成JPA 是原生MyBatis-Plus 和 Xbatis 的 Starter 都齐全Solon 集成JPA 无法实现MyBatis-Plus3.5.9 可以Xbatis 有原生 Solon StarterGraalVM NativeJPA 和 Xbatis 都不支持MyBatis-Plus 3.5.17 支持。结论是JPA 有 Java EE 标准背书MP 有用户基数碾压Xbatis 的生态还需要时间。学习曲线学习曲线方面JPA 入门门槛低但精通门槛极高典型痛点是持久化上下文、懒加载、N 1、缓存机制使用者以为懂了上线就可能出问题MyBatis-Plus 入门门槛低精通门槛中典型痛点是 Wrapper 写复杂条件时嵌套地狱多表必须回 XMLXbatis 入门门槛中精通门槛中概念稍多Chain/QO/Model/VO但一旦理解就一通百通。结论是JPA 是“入门即巅峰深入即地狱”。MP 是“一马平川直到需要 JOIN”。Xbatis 是“前 3 天消化概念后面全是爽的”。最终裁决选谁如果项目以单表 CRUD 为主团队想快速出活应选 MyBatis-Plus其代码生成器实用社区方案多如果项目是标准的企业级应用有大量关联查询应选 Xbatis其 JOIN 不用 XMLVO 自动映射分页自动优化如果追求 Java EE 标准、DDD、纯面向对象应选 JPA但要准备好为 N 1 和复杂查询付出额外代价如果项目有 100 张表复杂报表还要跨数据库应选 Xbatis其单 Mapper 原生 JOIN SQL 模板优势明显如果已经有成熟的 MP 项目不想重构应继续使用 MP如果从 Spring Boot 迁移到 Solon应选 Xbatis其 Solon 原生集成MP 的 Solon 支持是后补的。一句话暴击JPA你以为它在帮你其实它在瞒你。N 1 的债迟早要还。MyBatis-Plus单表的神多表的狗。JOIN 的那一刻它把你丢回给了 MyBatis。Xbatis把 MyBatis 真正 ORM 化的框架。JOIN、VO、分页、多租户 ---- API 到哪能力到哪不需要 XML 救场。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
