MyBatis-Plus 查询时字段为空仍拼接eq条件？

Question

在使用 MyBatis-Plus 进行条件查询时，常见问题：当字段值为 `null` 时，仍拼接 `eq` 条件导致 SQL 异常或查询结果为空。例如，`queryWrapper.eq("status", status)` 中若 `status` 为 `null`，会生成 `status = NULL` 的 SQL，不仅查不出数据，还可能引发逻辑错误。虽然 MyBatis-Plus 支持链式调用和自动判空，但 `eq` 方法默认不进行参数为空判断，需手动添加 `Objects.nonNull()` 判断或使用 `StringUtils.isNotBlank()` 等条件控制，否则会导致冗余或错误的 SQL 拼接。如何优雅处理空值不参与条件拼接，是实际开发中高频遇到的技术痛点。

Answer 1

一、MyBatis-Plus 条件查询中 null 值处理的常见问题

在使用 MyBatis-Plus 构建动态查询时，QueryWrapper 提供了链式调用的便捷方式，例如：

queryWrapper.eq("status", status);

当 status 为 null 时，该语句仍会拼接 SQL 片段：status = NULL。这不仅无法匹配任何记录（因为 SQL 中 = NULL 永远为 false），还可能导致全表扫描或逻辑错误。

开发者常误以为 MyBatis-Plus 会自动忽略空值，但实际上，eq 方法默认不进行判空，必须显式控制条件拼接逻辑。

二、问题本质分析：为何 eq 不自动跳过 null？

MyBatis-Plus 的设计哲学是“按需构建”，即开发者明确表达意图。框架无法判断 null 是“用户未输入”还是“需要查询 NULL 值”的语义。

例如，某些业务场景下确实需要查询字段为 NULL 的记录，此时应使用：

queryWrapper.isNull("status");

因此，框架将判空决策权交予开发者，避免歧义。

三、常规解决方案对比

方案	实现方式	优点	缺点
手动判空	if (status != null) queryWrapper.eq("status", status);	简单直接，控制精确	代码冗余，可读性差
Objects.nonNull + 链式	queryWrapper.eq(Objects.nonNull(status), "status", status)	一行解决，MyBatis-Plus 原生支持	需记忆参数顺序
StringUtils 判断字符串	queryWrapper.eq(StringUtils.isNotBlank(name), "name", name)	适用于字符串类型	不通用，仅限特定类型

四、推荐实践：利用条件构造器的布尔开关机制

MyBatis-Plus 提供了带布尔条件的重载方法，这是最优雅的解决方案：

queryWrapper.eq(status != null, "status", status)
              .like(StringUtils.isNotBlank(keyword), "name", keyword)
              .gt(age != null, "age", age);

上述写法中，第一个参数为布尔值，决定是否拼接该条件。这种方式兼具简洁性与可读性，是官方推荐模式。

五、进阶技巧：封装通用判空工具类

对于高频使用的判空逻辑，可封装工具方法提升复用性：

public class QueryWrapperUtils {
    public static <T> boolean nonNull(T value) {
        return Objects.nonNull(value);
    }
    
    public static boolean notBlank(String str) {
        return StringUtils.isNotBlank(str);
    }
}

调用时：

queryWrapper.eq(nonNull(status), "status", status);

六、结合 Lambda 表达式提升类型安全

使用 LambdaQueryWrapper 可避免字段名硬编码：

LambdaQueryWrapper<User> wrapper = new LambdaQueryWrapper<>();
wrapper.eq(Objects.nonNull(status), User::getStatus, status);

此方式在重构时具备编译期检查能力，降低出错概率。

七、流程图：条件拼接决策逻辑

graph TD
            A[开始构建查询] --> B{字段值是否为null?}
            B -- 是 --> C[跳过该条件]
            B -- 否 --> D[拼接eq条件]
            C --> E[继续下一个条件]
            D --> E
            E --> F{是否还有其他条件?}
            F -- 是 --> B
            F -- 否 --> G[执行查询]

八、边界场景考虑

• Integer 类型的 0 与 null 的区分：不能简单用 != null 判断数值是否有效
• String 类型需区分 "" 与 null，建议使用 StringUtils.isNotBlank()
• 集合类型可用 CollectionUtils.isNotEmpty() 控制 in 查询
• 时间类型注意 LocalDateTime 是否为 null
• 枚举类型传参时也需判空，防止 NPE
• 前端传参缺失时，DTO 字段可能为 null，需统一处理策略
• 分页查询中，排序字段也可能为空，需动态判断

九、性能与最佳实践建议

1. 优先使用带布尔条件的 eq(boolean condition, ...) 方法
2. 避免在循环中频繁创建 Wrapper 实例
3. 复杂查询建议拆分为多个小方法，提升可维护性
4. 结合 Spring Validation 在 Controller 层预校验参数
5. 使用 AOP 或拦截器统一处理公共查询条件
6. 对高频查询建议添加缓存层，减少数据库压力
7. 开启 MyBatis 日志，便于调试生成的 SQL

十、扩展思考：自定义 Wrapper 增强

可通过继承 QueryWrapper 实现智能判空封装：

public class SmartQueryWrapper<T> extends QueryWrapper<T> {
    public SmartQueryWrapper<T> smartEq(String column, Object value) {
        if (Objects.nonNull(value)) {
            this.eq(column, value);
        }
        return this;
    }
}

进一步可结合泛型和反射实现更智能的自动判空策略。