在 MyBatis-Plus 的开发体系中，这两种写法的专业术语通常被称为：
- Mapper 自带的方法 ：称为通用 CRUD 方法 （或内置方法、零 SQL 开发）。它是通过让 Mapper 接口继承
BaseMapper<T>获得的。 - 使用 XML 的写法 ：称为自定义 SQL（或原生 MyBatis XML 映射方式）。它是在 XML 文件中手写 SQL 语句，由框架进行映射。
在实际的企业级开发中，通常遵循 "70% 通用 CRUD + 30% 自定义 SQL" 的混合开发模式。以下是这两种写法的具体使用场景与边界：
一、 什么时候使用 Mapper 自带的方法（通用 CRUD）
核心定位：解决"重复 SQL"的问题，主打单表操作和条件组合，无需手写 SQL。
适用场景：
- 单表的基础增删改查 ：如根据 ID 查询、新增单条数据、根据主键更新或删除等。这类操作逻辑稳定，使用
BaseMapper内置方法（如insert,selectById,updateById）最简洁。 - 后台管理系统的列表页 ：典型的管理后台接口通常包含"条件查询 + 分页 + 排序 + 可选条件"。使用
LambdaQueryWrapper进行条件拼接（如eq,like,between）非常方便，本质上是"拼条件，不拼结构"。 - 纯粹的 CRUD 服务层：当 Service 层的职责非常纯粹，只负责数据的进出，不需要理解复杂的业务逻辑时，使用自带方法代码短、维护成本低。
- 动态条件查询 ：利用
Wrapper条件构造器，可以根据前端传入的参数动态拼接WHERE条件，避免了原生 MyBatis 中繁琐的<if>标签拼接。
二、 什么时候使用 XML 手写 SQL
核心定位：解决"复杂 SQL"的问题，提供对数据库操作的绝对控制权。
适用场景：
- 多表 JOIN 关联查询：一旦涉及多表关联，字段来源复杂，结果集结构不稳定。如果强行用 Wrapper 拼 JOIN 或子查询，代码会极其难以阅读和调试，此时应回归 XML。
- 复杂的统计与报表查询 ：当查询的目的不是获取原始数据，而是返回聚合结果（如
GROUP BY统计、计算字段、返回 VO 对象）时，本质是数据加工，使用 XML 配合ResultMap更加清晰。 - 需要深度 SQL 优化与索引控制：当进入"数据库工程"层面，需要关心查询是否走索引、JOIN 顺序是否正确、执行计划是否合理时，手写 SQL 是必要的，因为可控性比省代码更重要。
- 大批量数据操作 ：对于海量数据的批量插入或更新，虽然 MP 提供了
saveBatch，但在极端性能要求下，手写基于<foreach>的批量 SQL 性能更好。
三、 总结与判断标准
在健康的项目架构中，两者并非互斥，而是互补的。MyBatis-Plus 完全兼容原生 MyBatis，你可以让 Mapper 接口既继承 BaseMapper，又在 XML 中定义自定义方法，两者混合使用。
一个非常实用的工程化判断标准是：
如果这个 SQL，你愿意直接在数据库客户端里单独执行、调试、优化，那就手写 XML 。
如果这个 SQL 只是单表 CRUD 的一种表达，那就用 Mapper 自带的方法 + Wrapper。
懂工具的边界，把精力留给真正值得手写 SQL 的复杂业务，才是成熟的开发实践。
需要我整理一份 LambdaQueryWrapper 常用条件拼接的速查表吗？比如 eq、like、between 这些该怎么写。