摘要：作为 Java 持久层开发的两大核心工具，Mybatis 与 MyBatis-Plus（简称 MP）并非对立关系，而是“基础框架” 与 “增强工具”的互补组合。但在互联网大厂的高并发、复杂业务场景中，两者的技术选型差异直接影响开发效率、系统性能和维护成本，核心
作为 Java 持久层开发的两大核心工具，Mybatis 与 MyBatis-Plus（简称 MP）并非对立关系，而是“基础框架” 与 “增强工具”的互补组合。但在互联网大厂的高并发、复杂业务场景中，两者的技术选型差异直接影响开发效率、系统性能和维护成本，核心区别可概括为以下 3 点：
Mybatis：本质是 “半 ORM 框架”，核心价值在于 **“灵活可控”** —— 通过 XML / 注解自定义 SQL，支持复杂查询、动态 SQL 拼接，完全适配大厂 “业务逻辑复杂、SQL 优化需求高” 的场景（如金融核心系统、电商订单系统）。但它的痛点也很明显：重复编码量大（如 CRUD 方法、分页逻辑）、字段映射需手动维护、无统一的条件构造器。MyBatis-Plus：基于 Mybatis 开发的增强工具包（非替换），核心定位是 “简化开发、提升效率”—— 在完全兼容 Mybatis 的基础上，封装了 CRUD 通用接口、条件构造器、分页插件等功能，解决了 Mybatis “重复造轮子” 的问题，更适配大厂 “快速迭代、团队协作” 的需求（如中台系统、运营后台）。Mybatis 依赖极简（仅核心 jar 包），无额外第三方依赖，扩展性极强 —— 大厂可基于 Mybatis 原生接口自定义插件（如 SQL 监控、权限控制），完全适配内部中间件生态（如自研数据库连接池、分库分表框架）。MyBatis-Plus 完全依赖 Mybatis（需兼容对应版本），在增强功能的同时保持了 “零侵入” 特性 —— 大厂既可以享受 MP 的高效开发能力，又能保留 Mybatis 的原生扩展接口（如自定义 TypeHandler、Plugin），不会绑定技术栈。要在大厂场景中灵活选型，必须理解两者核心功能的实现原理，避免 “知其然不知其所以然” 导致的技术风险：
Mybatis 的核心是 “SQL 映射机制”，底层依赖 JDK 动态代理实现接口与 SQL 的绑定，流程如下：
加载配置文件（mybatis-config.xml）与 Mapper 接口、XML 映射文件；通过 SqlSessionFactory 创建 SqlSession（数据库会话）；调用 Mapper 接口方法时，动态代理拦截请求，根据接口全限定名 + 方法名匹配 XML 中的 SQL 语句；解析 SQL 中的参数占位符，通过 TypeHandler 处理参数类型转换；执行 SQL 并将结果集通过 ResultMap 映射为 Java 对象。大厂关注的核心点：Mybatis 的 SQL 与代码分离设计，使得 DBA 可直接优化 XML 中的 SQL，适配 “SQL 性能敏感” 场景（如大数据量查询、复杂联表查询），这也是金融、电商等核心系统首选 Mybatis 的关键原因。
MP 的增强功能完全基于 Mybatis 的扩展点实现，无底层改造，核心原理包括 3 点：
通用 CRUD 实现：通过 BaseMapper 接口定义标准化 CRUD 方法，利用反射获取 Entity 的表名、字段名，动态生成 SQL（如 SELECT * FROM 表名 WHERE id=?），避免重复编码；条件构造器原理：QueryWrapper 通过链式调用封装查询条件（如 eq ("name","张三").ge ("age",18)），底层拼接 SQL 片段，最终通过 Mybatis 的 SqlSource 接口生成完整 SQL；分页插件原理：实现 Mybatis 的 Interceptor 接口，拦截 Executor 的 query 方法，在 SQL 执行前自动拼接 LIMIT（MySQL）/ROWNUM（Oracle）语句，支持物理分页（比 PageHelper 的内存分页更适合大厂高数据量场景）。大厂关注的核心点：MP 的动态 SQL 生成机制完全兼容 Mybatis 的原生 SQL，既可以用 MP 的条件构造器快速开发，也可以在复杂场景下切换为 XML 自定义 SQL，不会牺牲灵活性。
大厂后端开发的核心需求是 “兼顾效率与性能”，以下结合实际业务场景，给出两者的选型建议与实战代码（基于 Spring Boot 2.x + Mybatis 3.5.x + MP 3.5.x）：
选 Mybatis 的场景：核心业务模块（如订单、支付）、复杂 SQL 场景（多表联查、子查询）、SQL 性能优化需求高的模块；选 MyBatis-Plus 的场景：非核心业务模块（如用户管理、配置中心）、CRUD 为主的简单业务、快速迭代的中台系统；混合使用场景：核心 SQL 用 Mybatis XML 自定义，基础 CRUD 用 MP 的 BaseMapper，兼顾灵活与效率（大厂最常用方案）。org.mybatis.spring.bootmybatis-spring-boot-starter2.2.2com.baomidoumybatis-plus-boot-starter3.5.3.1mysqlmysql-connector-javaruntime（2）Entity 定义（MP 注解简化映射）
// 大厂规范：Entity字段与数据库字段保持驼峰命名，通过MP注解快速配置@TableName("t_order") // 对应数据库表名public class OrderEntity {@TableId(type = IdType.AUTO) // 主键自增（大厂常用雪花算法：IdType.ASSIGN_ID）private Long id;@TableField("order_no") // 数据库字段名（驼峰自动映射可省略）private String orderNo;private BigDecimal amount;@TableField(exist = false) // 非数据库字段private String userName;// getter/setter省略（可通过Lombok简化）}// 继承MP的BaseMapper，获得CRUD通用方法public interface OrderMapper extends BaseMapper{ // 复杂查询：用Mybatis XML自定义SQL（大厂核心业务常用） @Select("SELECT o.*, u.user_name FROM t_order o " + "LEFT JOIN t_user u ON o.user_id = u.id " + "WHERE o.create_time BETWEEN #{startTime} AND #{endTime} " + "AND o.amount >= #{minAmount}") ListselectOrderWithUser(@Param("startTime") LocalDateTime startTime, @Param("endTime") LocalDateTime endTime, @Param("minAmount") BigDecimal minAmount); }// 继承MP的ServiceImpl，获得通用Service方法@Servicepublic class OrderServiceImpl extends ServiceImplimplements OrderService { @Override public ListgetOrderList(LocalDateTime startTime, LocalDateTime endTime, BigDecimal minAmount) { // 1. 简单查询：用MP条件构造器（非核心业务） QueryWrapperqueryWrapper = new QueryWrapper; queryWrapper.ge("amount", 100); // 金额>=100 ListsimpleList = baseMapper.selectList(queryWrapper); // 2. 复杂查询：调用Mybatis自定义SQL（核心业务） ListcomplexList = baseMapper.selectOrderWithUser(startTime, endTime, minAmount); return complexList; } }// 1. 配置分页插件（Spring Boot配置类）@Configurationpublic class MybatisPlusConfig {@Beanpublic MybatisPlusInterceptor mybatisPlusInterceptor {MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor;// 添加分页插件（指定数据库类型，避免SQL语法差异）interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL));return interceptor;}}// 2. 分页查询实战@Overridepublic IPagegetOrderPage(int pageNum, int pageSize) { // MP分页对象 Pagepage = new Page(pageNum, pageSize); // 条件构造器：查询未支付订单 QueryWrapperqueryWrapper = new QueryWrapper; queryWrapper.eq("status", 0); // 分页查询（自动拼接LIMIT语句） IPageorderPage = baseMapper.selectPage(page, queryWrapper); // 大厂优化：分页结果处理（如总数缓存、避免count查询） return orderPage; }在互联网大厂的高并发、高可用场景中，使用 Mybatis 与 MP 时需重点关注以下 5 个坑点，避免线上故障：
问题：使用eq("name", "${name}")（$ 符号）会导致 SQL 注入，而eq("name", name)（# 符号）是参数绑定，安全无风险；大厂规范：所有条件构造器查询必须使用参数绑定（默认就是 #），禁止直接拼接字符串。问题：MP 3.5.x 需搭配 Mybatis 3.5.x，若使用 Mybatis 3.4.x 会出现方法找不到异常；解决方案：在 pom.xml 中锁定 Mybatis 版本，跟随 MP 的依赖推荐版本（参考 MP 官方文档）。问题：部分开发者完全依赖 MP 的条件构造器，复杂 SQL 也强行拼接，导致后期优化困难；大厂规范：核心业务的复杂 SQL 优先用 Mybatis XML 自定义，MP 仅用于基础 CRUD，避免技术绑定。Mybatis 是 Java 持久层的 “基石”，提供极致的灵活性和可控性，适配大厂核心业务场景；MyBatis-Plus 是 “效率工具”，在不牺牲灵活性的前提下简化开发，适配快速迭代的非核心业务。大厂后端开发者的最优实践是：混合使用两者—— 基础 CRUD 用 MP 提升效率，复杂 SQL 用 Mybatis 保证性能，同时规避上述坑点，兼顾开发效率与系统稳定性。
如果你的项目正面临技术选型困惑，或在使用过程中遇到具体问题，欢迎在评论区留言讨论！
来源：有趣的科技君