Xbatis vs MyBatis-Plus：两大 MyBatis 增强框架全方位对比

一、引言

Java 后端开发中，ORM 框架选型始终是一个绕不开的话题。MyBatis 生态之所以长盛不衰，正是因为它在灵活性和开发效率之间找到了最佳平衡点。而在这个生态中，MyBatis-Plus 和 Xbatis 是最具代表性的两个增强框架。

MyBatis-Plus 深耕多年，社区庞大；Xbatis 后来居上，设计激进。本文将从设计哲学、核心 API、多表查询、分页机制、功能覆盖、生态成熟度六个维度进行全面对比。

二、基本信息

三、设计哲学

MyBatis-Plus：优秀的「助手」

MP 的口号是「只做增强不做改变」。它在 MyBatis 之上提供通用 Mapper、条件构造器、分页插件，但不过度封装。复杂场景下推荐回退到 XML 手写 SQL。你可以把它理解为给 MyBatis 装上了一个"智能补全"——帮你省掉重复的 CRUD，但碰到硬骨头还是你自己来。

Xbatis：彻底的「重构者」

Xbatis 的口号更激进：「让写代码像写 SQL 一样流畅」。它用链式 DSL 重新定义了数据访问层，试图让开发者几乎不写 SQL。多表 JOIN、子查询分页、嵌套结果映射……这些 MyBatis-Plus 不敢碰的硬骨头，Xbatis 全部内置解决。

一句话总结：MP 是 MyBatis 的「舒适外挂」，Xbatis 是 MyBatis 的「完全体变身」。

四、核心 API 对比

这是两者差异最直观的地方。

MyBatis-Plus：Wrapper 作为参数

LambdaQueryWrapper<User> wrapper = Wrappers.<User>lambdaQuery()
        .like(User::getUserName, "张")
        .eq(User::getGender, 1)
        .gt(User::getAge, 24);
List<User> users = userMapper.selectList(wrapper);
复制

Wrapper 是一个独立的条件对象，作为参数传给 Mapper 方法。写完条件还要再调一次 Mapper，步骤是分离的。

Xbatis：QueryChain 一路到底

List<User> users = QueryChain.of(userMapper)
        .like(User::getUserName, "张")
        .eq(User::getGender, 1)
        .gt(User::getAge, 24)
        .list();
复制

QueryChain 是方法的主体，条件、分页、排序、JOIN 全部一气呵成。没有中间对象，写起来更像一条完整的 SQL 语句。

聚合函数对比

// MyBatis-Plus：字段名硬编码，拼错不会报错
QueryWrapper<User> wrapper = Wrappers.query()
    .select("id", "user_name", "max(birthday)", "avg(birthday) as sex_avg");

// Xbatis：Lambda 表达式，编译期检查
List<User> users = QueryChain.of(userMapper)
        .select(User::getId)
        .select(User::getUserName, c -> c.max())
        .select(User::getBirthday, c -> c.avg().as("sex_avg"))
        .list();
复制

Xbatis 的聚合函数写法和普通字段一样享受 IDE 自动补全和重构支持，MP 只能是字符串硬编码。

五、功能对比总表

以下基于双方官方文档整理（✅ 支持 ❌ 不支持 ⚠️ 需第三方）：

六、重头戏：多表查询

这是两者差距最大的地方。

MyBatis-Plus：官方不支持，依赖第三方

MP 官方对多表 JOIN 的态度很明确——复杂关联请回退 XML。你只能借助社区项目 mybatis-plus-join（yulichang 维护），需要额外引入依赖、继承 MPJBaseMapper，配置拦截器，而且存在版本兼容问题。

Xbatis：原生一等公民

// 极简写法：两参数搞定 LEFT JOIN
List<SysUser> list = QueryChain.of(sysUserMapper)
        .leftJoin(SysUser::getRoleId, SysRole::getId)
        .leftJoin(SysUser::getDeptId, SysDept::getId)
        .like(SysUser::getUserName, "张")
        .list();

// 返回 VO，自动嵌套映射
List<SysUserVo> voList = QueryChain.of(sysUserMapper)
        .leftJoin(SysUser::getRoleId, SysRole::getId)
        .leftJoin(SysUser::getDeptId, SysDept::getId)
        .returnType(SysUserVo.class)
        .paging(Pager.of(1, 10));
复制

配合 @NestedResultEntity 注解，关联表字段可以自动嵌套到 VO 的子对象中，甚至支持多层嵌套。这在你做「用户 → 角色 → 权限」这种多级关联时极其舒适。

@Fetch：杀手级特性

// 查用户时，自动 Fetch 角色和部门信息，避免 N+1
@Data
public class SysUserVo {
    private Integer id;
    private String userName;

    @Fetch(source = SysUser.class, property = "roleId", target = SysRole.class)
    private SysRole role;

    @Fetch(source = SysUser.class, property = "deptId", target = SysDept.class)
    private SysDept dept;
}
复制

@Fetch 可以在查询后自动批量关联查询其他表的数据，并且框架会智能合并为批量查询，有效避免 N+1 问题。从 v1.10.1 开始甚至支持 合并查询——原来需要两次查询的数据，合并为一次 JOIN 查询搞定。

七、分页对比

MyBatis-Plus：JsqlParser 解析

MP 的分页依赖 JsqlParser 解析原始 SQL，然后包裹 COUNT 和 LIMIT。优点是通用性强，缺点是：

• 引入了 SQL 解析开销
• 复杂 SQL（CTE、UNION）可能解析失败
• 子查询分页不支持

Xbatis：无解析设计

Xbatis 因为自己生成 SQL，天然知道如何 COUNT 和分页，完全不需要 SQL 解析。这意味着：

• 更轻量：没有 JsqlParser 依赖
• 更高性能：省去解析步骤
• 子查询也能分页：这是 MP 做不到的

八、部分字段更新对比

// 需求：更新 userName、age、birthday（含 null），其余字段不动

// ===== Xbatis =====
Account account = UpdateEntity.of(Account.class);
account.setId(100);
account.setUserName("michael");
account.setAge(18);
account.setBirthday(null);
accountMapper.update(account, Account::getBirthday); // 指定 birthday 允许 null

// ===== MyBatis-Plus =====
LambdaUpdateWrapper<Account> wrapper = new LambdaUpdateWrapper<>();
wrapper.eq(Account::getId, 100);
wrapper.set(Account::getUserName, "xxx");
wrapper.set(Account::getAge, 18);
wrapper.setSql("birthday=NULL"); // null 必须写原生 SQL！
accountMapper.update(null, wrapper);
复制

Xbatis 用 UpdateEntity 设计，null 值也能优雅更新。MP 只能退回到 setSql 手写。

九、社区与生态

十、选型建议

选 Xbatis，如果：

• ✅ 你的业务多表关联查询频繁，不想反复写 XML
• ✅ 你追求极简 API，希望一套链式调用搞定一切
• ✅ 项目需要跨数据库兼容，一套代码跑 MySQL + PostgreSQL + Oracle
• ✅ 你需要子查询分页、嵌套结果映射等高级特性
• ✅ 你愿意尝鲜，接受新框架的成长过程

选 MyBatis-Plus，如果：

• ✅ 你的项目以单表 CRUD 为主，复杂查询走 XML 完全够用
• ✅ 你需要成熟的代码生成器快速搭建项目骨架
• ✅ 团队更看重社区活跃度和问题可搜索性
• ✅ 你需要 MybatisX 插件在 IDEA 中的跳转和补全体验
• ✅ 项目已经深度使用 MP，迁移成本太高
• ✅ 你是保守派，「稳定压倒一切」

十一、写在最后

MyBatis-Plus 像一位经验丰富的老工程师——稳重、可靠、什么场面都见过。16K Star 不是白来的，它用十年时间证明了「只做增强不做改变」这条路走得通。

Xbatis 则像一位野心勃勃的年轻架构师——它不甘心只做 MyBatis 的补丁，而是试图重新定义「基于 MyBatis 的 ORM 应该长什么样」。多表 JOIN、@Fetch、子查询分页、DDL 自动化……这些 MyBatis-Plus 十年没碰的领域，Xbatis 在两年内全部拿下。

没有最好的框架，只有最适合你业务的框架。 如果你的项目以单表操作为主，MP 依然是最稳妥的选择。如果你的业务充满了复杂的多表关联、多数据库兼容需求，Xbatis 可能让你少写一半的代码。