Java 持久层框架的选择很少是“谁碾压谁”的问题。原生 MyBatis、MyBatis-Plus、xbatis、Spring Data JPA / Hibernate 解决的是相近问题，但它们把复杂度放在了不同位置：有的把 SQL 交给你，有的把 CRUD 包起来，有的强调对象模型和规范，有的试图在类型安全、动态查询和开发效率之间找平衡。
四类框架的真实分工
原生 MyBatis 的核心优势是可控。SQL 写在 XML 或注解里，执行计划、索引命中、复杂 join、分页策略都能直接落到数据库层面。代价也很明显：样板代码多，字段变更时 XML、Mapper、DTO 容易一起改漏。
MyBatis-Plus 是对 MyBatis 的增强。它在国内项目里常见，因为它把单表 CRUD、分页、条件构造器、代码生成这些高频工作做成了标准件。它适合“业务表很多、查询大多不复杂、团队已经习惯 SQL 思维”的系统。
Spring Data JPA / Hibernate 代表另一条路线：以实体关系和领域模型为中心，依赖 ORM 自动生成 SQL，并提供国际化生态里更稳定的规范基础。它在关联模型清晰、事务边界明确、团队熟悉 JPA 语义时很强；但一旦遇到复杂报表、手写 SQL 优化、N+1 查询治理，工程纪律要求会明显提高。
xbatis 的定位可以理解为：试图在 MyBatis 生态的 SQL 可控性和更现代的查询构建体验之间取平衡。由于不同团队对 xbatis 的接入方式可能不同，评估时不要只看“能不能少写代码”，更要看它在复杂查询、类型安全、IDE 重构、插件生态、团队学习成本上的实际表现。
对比时不要只盯 CRUD
CRUD 只是持久层最浅的一层。真正拉开差距的地方通常在这些场景：
- 复杂查询：多表 join、动态 where、聚合、窗口函数，谁更容易写清楚、查得准、调得动。
- 变更成本：字段重命名、表结构迁移、DTO 调整后，编译期能发现多少问题。
- 性能透明度：生成 SQL 是否容易观察，慢查询是否容易定位。
- 团队熟悉度：框架越“魔法”，越需要统一规范和 code review 清单。
- 生态兼容：分页、租户、逻辑删除、审计字段、乐观锁、数据权限是否有成熟方案。
如果项目是大量管理后台、单表操作占多数，MyBatis-Plus 往往能把开发速度拉上去。如果项目是交易、风控、报表这类 SQL 很重的系统，原生 MyBatis 仍然有强生命力。如果项目强调领域模型和跨团队规范，JPA / Hibernate 的价值更明显。xbatis 则值得在“想保留 SQL 可控性，又想减少动态查询样板代码”的团队里试点。
可以这样实践：用同一组用例做框架选型 Spike
不要凭印象选 ORM。可以拿一张真实业务表，写 4 个查询：单表分页、动态条件、多表关联、批量更新。下面是一个可复制改造的最小验收脚本，用 H2 初始化一张 orders 表，便于你把不同框架接到同一个 schema 上比较生成 SQL、代码量和可测试性。
mkdir -p orm-spike/src/main/resources
cat > orm-spike/src/main/resources/schema.sql <<'SQL'
CREATE TABLE orders (
id BIGINT PRIMARY KEY,
user_id BIGINT NOT NULL,
status VARCHAR(32) NOT NULL,
amount DECIMAL(12,2) NOT NULL,
created_at TIMESTAMP NOT NULL
);
INSERT INTO orders(id, user_id, status, amount, created_at) VALUES
(1, 1001, 'PAID', 199.00, TIMESTAMP '2025-01-01 10:00:00'),
(2, 1001, 'CANCELLED', 59.90, TIMESTAMP '2025-01-02 11:00:00'),
(3, 1002, 'PAID', 899.00, TIMESTAMP '2025-01-03 12:00:00');
SQL
再定义一份统一验收目标。无论用 MyBatis、MyBatis-Plus、xbatis 还是 JPA，都必须完成同一个方法，而不是各写各的 demo：
import java.math.BigDecimal;
import java.time.LocalDateTime;
import java.util.List;
public interface OrderQueryPort {
List<OrderSummary> search(
Long userId,
String status,
BigDecimal minAmount,
LocalDateTime createdAfter,
int limit,
int offset
);
}
public record OrderSummary(
Long id,
Long userId,
String status,
BigDecimal amount,
LocalDateTime createdAt
) {}
原生 MyBatis 可以这样落地，SQL 完全显式，适合复杂查询继续扩展：
<select id="search" resultType="com.example.OrderSummary">
SELECT id, user_id AS userId, status, amount, created_at AS createdAt
FROM orders
WHERE 1 = 1
<if test="userId != null">AND user_id = #{userId}</if>
<if test="status != null">AND status = #{status}</if>
<if test="minAmount != null">AND amount >= #{minAmount}</if>
<if test="createdAfter != null">AND created_at >= #{createdAfter}</if>
ORDER BY created_at DESC
LIMIT #{limit} OFFSET #{offset}
</select>
MyBatis-Plus 可以把单表动态条件写进 Java 代码。下面示例用于表达实践方式，实体字段名和 mapper 名称需要按你的项目调整：
LambdaQueryWrapper<OrderEntity> wrapper = Wrappers.lambdaQuery(OrderEntity.class)
.eq(userId != null, OrderEntity::getUserId, userId)
.eq(status != null, OrderEntity::getStatus, status)
.ge(minAmount != null, OrderEntity::getAmount, minAmount)
.ge(createdAfter != null, OrderEntity::getCreatedAt, createdAfter)
.orderByDesc(OrderEntity::getCreatedAt)
.last("LIMIT " + limit + " OFFSET " + offset);
List<OrderEntity> rows = orderMapper.selectList(wrapper);
JPA / Hibernate 可以用 Specification 或 Criteria API。它的优势是实体模型统一，短板是生成 SQL 必须被持续观察：
Specification<OrderEntity> spec = (root, query, cb) -> {
List<Predicate> predicates = new ArrayList<>();
if (userId != null) predicates.add(cb.equal(root.get("userId"), userId));
if (status != null) predicates.add(cb.equal(root.get("status"), status));
if (minAmount != null) predicates.add(cb.greaterThanOrEqualTo(root.get("amount"), minAmount));
if (createdAfter != null) predicates.add(cb.greaterThanOrEqualTo(root.get("createdAt"), createdAfter));
query.orderBy(cb.desc(root.get("createdAt")));
return cb.and(predicates.toArray(Predicate[]::new));
};
xbatis 的试点也建议放到这组验收里。由于项目 API 版本可能不同，可以把目标写死：同样的过滤条件、同样的排序分页、必须能打印最终 SQL、字段重命名时最好能被编译器或测试发现。不要只比较“代码行数”，要比较线上排障时能不能看懂。
选型建议：把框架放进团队约束里
可以按下面这张清单做决策：
| 场景 | 更可能适合 |
|---|---|
| SQL 复杂、DBA 深度参与、性能调优频繁 | 原生 MyBatis |
| 管理后台多、单表 CRUD 多、国内生态插件依赖多 | MyBatis-Plus |
| 领域模型稳定、团队熟悉 JPA、希望靠规范统一数据访问 | Spring Data JPA / Hibernate |
| 想保留 MyBatis 式可控性，同时探索更轻的动态查询写法 | xbatis |
真正的风险不在框架名字，而在“不设边界”。MyBatis-Plus 项目里随处 .last() 拼 SQL，会把安全和可维护性打穿；JPA 项目里不管 fetch 策略，会被 N+1 查询拖垮；原生 MyBatis 如果没有 XML 规范和测试，字段变更会变成暗雷；xbatis 如果团队还没形成使用约定，也可能变成另一套无人熟悉的抽象。
我的建议是：新项目先用 1 到 2 天做 spike，把真实业务查询写一遍，打开 SQL 日志，补一组集成测试，再决定。框架不是奖杯，是维护成本的分配器。谁更强，最终要看它把复杂度放在了你们团队最擅长处理的位置上。