Xbatis、JPA、MyBatis-Plus 怎么选：别只看省代码，要看 SQL 控制权

预计阅读时间：10 分钟

同样是 Java 持久层框架，JPA、MyBatis-Plus 和 Xbatis 解决的不是同一个问题。来源摘要里把三者的核心差异说得很直接：JPA 倾向于“你操作对象，SQL 我来生成”，MyBatis-Plus 是 MyBatis 的增强工具，帮你少写模板代码，但复杂 SQL 的方向盘仍在开发者手里。Xbatis 则通常被放在“更轻、更显式、更贴近 SQL”的候选里讨论。选型时真正要问的不是“谁更先进”，而是你的团队愿意把多少 SQL 控制权交给框架。

三种思路，不是三种语法糖

JPA 的设计哲学是全自动 ORM。它把数据库表映射为实体对象，开发者通过 Repository、EntityManager 或对象关系来表达读写意图。优点很明显：CRUD 开发速度快，领域模型清晰时写起来顺滑。代价也同样明显：SQL 生成过程容易变成黑盒，N+1 查询、懒加载边界、级联更新、脏检查触发时机，都可能在压测或线上慢查询里才暴露。

MyBatis-Plus 的姿态更像“给 MyBatis 加助力”。它不试图替你隐藏 SQL 世界，而是在 MyBatis 之上补齐通用 Mapper、条件构造器、分页、代码生成等能力。简单 CRUD 少写很多样板，复杂查询仍然可以回到 XML 或注解 SQL。它适合那些既想提高效率，又不愿放弃 SQL 可见性的团队。

Xbatis 这类框架常被拿来和 MyBatis-Plus、JPA 比较，是因为它也站在“减少样板代码”和“保留 SQL 意识”之间。由于不同版本和生态细节需要以项目实际文档为准，本文不把未给出的能力当作事实展开。更稳妥的判断方式是：把它放进同一套选型测试里，验证它在动态查询、分页、事务、复杂 join、SQL 可观测性上的表现。

黑盒越强，越要补可观测性

JPA 最大的风险不是“会生成 SQL”，而是“生成了你没意识到的 SQL”。在业务早期，这种自动化会让开发体验很好；到了数据量上来、表关系复杂、接口延迟敏感时，自动生成 SQL 的成本就需要被明确管理。

MyBatis-Plus 的风险在另一边：它让 CRUD 很快，但团队容易把 Wrapper 写成另一种不可读 DSL。短查询还好，一旦条件拼接、权限过滤、租户隔离、排序分页混在一起，代码可读性可能不如一段清楚的 SQL。

Xbatis 若作为候选，也应该重点检查两件事：它到底隐藏了多少 SQL 细节，以及当默认能力不够时，能不能自然退回显式 SQL。持久层框架最怕“简单场景很优雅，复杂场景绕半天”。

可以这样实践：用同一个查询压测三类框架的边界

选型不要只看 README，也不要只看 CRUD 示例。可以拿一个真实业务查询做最小验证：按状态、时间范围、关键词查询用户列表，并分页返回。下面用 MyBatis-Plus 写一个可改造的 Spring Boot 示例，重点看它如何保留 SQL 控制感。

需要替换的地方：数据库连接、表结构、包名。示例使用 H2 内存数据库，复制后可以直接跑通最小流程。

<!-- pom.xml 关键依赖片段 -->
<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>3.3.5</version>
  </dependency>
  <dependency>
    <groupId>com.baomidou</groupId>
    <artifactId>mybatis-plus-spring-boot3-starter</artifactId>
    <version>3.5.9</version>
  </dependency>
  <dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <version>2.3.232</version>
    <scope>runtime</scope>
  </dependency>
</dependencies>

# src/main/resources/application.yml
spring:
  datasource:
    url: jdbc:h2:mem:testdb;MODE=MySQL;DATABASE_TO_UPPER=false
    driver-class-name: org.h2.Driver
    username: sa
    password:
  sql:
    init:
      mode: always
mybatis-plus:
  configuration:
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

-- src/main/resources/schema.sql
CREATE TABLE users (
  id BIGINT PRIMARY KEY,
  name VARCHAR(64) NOT NULL,
  status VARCHAR(16) NOT NULL,
  created_at TIMESTAMP NOT NULL
);

INSERT INTO users VALUES
  (1, 'Alice', 'ACTIVE', '2024-01-10 10:00:00'),
  (2, 'Bob', 'LOCKED', '2024-02-12 11:00:00'),
  (3, 'Carol', 'ACTIVE', '2024-03-15 12:00:00');

// src/main/java/demo/User.java
package demo;

import com.baomidou.mybatisplus.annotation.TableName;
import java.time.LocalDateTime;

@TableName("users")
public class User {
  public Long id;
  public String name;
  public String status;
  public LocalDateTime createdAt;
}

// src/main/java/demo/UserMapper.java
package demo;

import com.baomidou.mybatisplus.core.mapper.BaseMapper;
import org.apache.ibatis.annotations.Mapper;

@Mapper
public interface UserMapper extends BaseMapper<User> {
}

// src/main/java/demo/App.java
package demo;

import com.baomidou.mybatisplus.core.conditions.query.LambdaQueryWrapper;
import com.baomidou.mybatisplus.extension.plugins.MybatisPlusInterceptor;
import com.baomidou.mybatisplus.extension.plugins.inner.PaginationInnerInterceptor;
import com.baomidou.mybatisplus.extension.plugins.pagination.Page;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController
public class App {
  private final UserMapper userMapper;

  public App(UserMapper userMapper) {
    this.userMapper = userMapper;
  }

  public static void main(String[] args) {
    SpringApplication.run(App.class, args);
  }

  @Bean
  MybatisPlusInterceptor mybatisPlusInterceptor() {
    MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor();
    interceptor.addInnerInterceptor(new PaginationInnerInterceptor());
    return interceptor;
  }

  @GetMapping("/users")
  public Page<User> users(
      @RequestParam(defaultValue = "ACTIVE") String status,
      @RequestParam(defaultValue = "") String keyword,
      @RequestParam(defaultValue = "1") long page,
      @RequestParam(defaultValue = "10") long size) {

    LambdaQueryWrapper<User> query = new LambdaQueryWrapper<User>()
        .eq(User::getStatus, status)
        .like(!keyword.isBlank(), User::getName, keyword)
        .orderByDesc(User::getCreatedAt);

    return userMapper.selectPage(Page.of(page, size), query);
  }
}

上面的 User 为了让 Lambda 方法引用可编译，需要补 getter。可以用 IDE 生成，也可以使用 Lombok：

// 如果使用 Lombok，可以把 User 改成这样
package demo;

import com.baomidou.mybatisplus.annotation.TableName;
import lombok.Data;
import java.time.LocalDateTime;

@Data
@TableName("users")
public class User {
  private Long id;
  private String name;
  private String status;
  private LocalDateTime createdAt;
}

运行和验证：

mvn spring-boot:run
curl 'http://localhost:8080/users?status=ACTIVE&keyword=a&page=1&size=10'

观察控制台打印的 SQL。这个动作非常关键：无论你评估 JPA、MyBatis-Plus 还是 Xbatis，都应该把“实际发出的 SQL”纳入验收，而不是只看 Java 代码是否漂亮。

选型时问这几个硬问题

如果团队偏领域建模，表关系稳定，业务查询以实体聚合为主，并且有人熟悉 JPA 的加载策略、事务边界和性能调优，JPA 可以带来很高的开发效率。它不是不能用于复杂系统，但必须把 SQL 日志、慢查询分析、fetch 策略和集成测试一起配上。

如果团队重视 SQL 可读性，业务报表、复杂筛选、手写优化较多，MyBatis-Plus 往往更稳。它把简单 CRUD 的体力活拿掉，又允许复杂查询回到 SQL。边界是：不要把 Wrapper 当成万能表达式，超过可读性阈值就写 XML 或自定义 Mapper。

如果考虑 Xbatis，建议用同一批业务用例做 PoC：单表 CRUD、动态条件、分页、批量写入、复杂 join、事务回滚、SQL 日志、迁移成本。不要只比较“代码行数”，还要比较新人能否读懂、线上问题能否定位、框架能力不够时能否绕开。

一个简短结论

JPA 是自动挡，开起来省心，但要懂它什么时候替你换挡；MyBatis-Plus 是带助力的手动挡，省力但方向仍在你手里；Xbatis 是否合适，要看它在你的复杂查询和可观测性要求下表现如何。

选持久层框架时，把 SQL 控制权、团队经验、调试成本和业务复杂度放在同一张表里。能让你少写代码的框架很多，能让你在凌晨两点快速定位慢 SQL 的框架，才是真正适合生产环境的框架。