MyBatis-Plus 使用 Wrapper 构建动态 SQL 有哪些优劣势？

MyBatis-Plus (MP) 提供的 Wrapper (如 QueryWrapper, LambdaQueryWrapper, UpdateWrapper, LambdaUpdateWrapper) 是其核心特性之一，它允许我们在开发时以面向对象的方式构建 SQL 的 WHERE 条件、ORDER BY、SELECT 字段列表等部分。与传统的 MyBatis 在 XML 文件中编写动态 SQL 相比，使用 Wrapper 优劣势如下：

使用 Wrapper 构建动态 SQL 查询的优势 (Advantages):

代码即查询，更 Java 化 (Code is Query, More Java-Centric):
- 查询逻辑完全在 Java 代码中完成，无需在 Java 和 XML 文件之间频繁切换上下文。
- 对于 Java 开发者来说，使用熟悉的链式调用 (fluent API) 构建查询条件通常更直观、更符合面向对象的思维。
- 易于利用 Java 的编程能力动态构建查询条件，例如根据复杂的业务逻辑 if/else 来添加不同的查询条件。
类型安全 (Type Safety - 特别是 LambdaWrapper):
- 使用 LambdaQueryWrapper 或 LambdaUpdateWrapper 时，可以通过方法引用 (如 User::getName) 来指定数据库字段，而不是硬编码字符串 (“name”)。
- 这带来了编译期检查的好处：如果实体类的字段名发生重名（rename），编译器会报错，强制你修改查询代码，极大的减少了因字段名拼写错误或重构遗漏导致的运行时错误。原生 XML 中的字符串则无法在编译期检查。
```
// Type-safe using LambdaWrapper
LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(User::getName, "John Doe").ge(User::getAge, 30);// Less safe using QueryWrapper with hardcoded strings
QueryWrapper<User> wrapperStr = new QueryWrapper<>();
wrapperStr.eq("name", "John Doe").ge("age", 30); // Typos in "name" or "age" only found at runtime
```
友好的 IDE 支持 (Better IDE Support):
- 在 IDE 中我们可以使用自动补全、语法高亮、重构等。
- 编写 Wrapper 时，可以方便的查看方法、参数提示。
代码简洁性 (Conciseness for Common Cases):
- 对于许多常见的、不太复杂的动态条件组合，使用 Wrapper 的链式调用通常比编写 XML 中的 <if>, <where>, <foreach> 等标签更简洁。
易于组合和复用 (Easier Composition & Reuse):
- 可以将构建 Wrapper 的部分逻辑封装成独立的方法或工具类，在不同的查询场景中复用，提高了代码的模块化程度。

使用 Wrapper 构建动态 SQL 查询的劣势 (Disadvantages):

复杂 SQL 的受限 (Limited Expressiveness for Complex SQL):
- 对于非常复杂的 SQL 查询，特别是涉及多表连接 (JOIN)、子查询、联合查询 (UNION)、复杂的聚合函数时，使用 Wrapper 可能会变得非常困难。
- 强行用 Wrapper 实现复杂 SQL 可能会导致代码可读性急剧下降，不如直接在 XML 中编写原生 SQL 清晰。
SQL 不直观，可读性下降 (SQL Obscurity & Reduced Readability for Complex Cases):
- 排查sql语句比较费劲，SQL 语句需要依赖日志输出或调试才能看到。
对 MP API 的学习成本 (Learning Curve for MP API):
- 开发者需要学习 Wrapper 提供的各种方法 (eq, ne, like, gt, lt, in, between, isNull, orderBy, groupBy, select, apply 等) 的用法和含义。
灵活性限制 (Flexibility Limitations):
- 虽然 Wrapper 提供了 apply() 方法来拼接原生 SQL 片段，但这在一定程度上破坏了 Wrapper 的类型安全和面向对象的优点。如果大量使用 apply()，可能还不如直接写 XML。
- 对于某些数据库特有的高级特性或优化提示 (Hints)，Wrapper 可能目前没有更好的支持。

总结与建议:

适用场景: Wrapper 非常适合处理单表或简单关联（可以通过 MP 的 Join 插件或少量自定义 SQL 补充）的动态条件查询，尤其是在需要类型安全和代码简洁性的场景下。对于大部分日常的 CRUD 和条件过滤、排序等操作，Wrapper 是极其高效的选择。
局限场景: 对于涉及复杂的多表连接、子查询、聚合、特定数据库函数等高级 SQL 操作，或者需要进行性能优化的场景，直接在 XML 中编写原生 SQL 通常是更佳、更灵活。
最佳实践: 混合使用 MyBatis-Plus 允许我们无缝的混合使用 BaseMapper 的通用方法、基于 Wrapper 的查询以及在 XML 中定义的自定义 SQL。
- 对于简单的、通用的、需要动态条件的查询，优先使用 LambdaWrapper 以获得类型安全和简洁性。
- 对于复杂的、性能敏感的、Wrapper 难以表达或表达不清的查询，毫不犹豫的在 XML 文件中编写。