如何利用Optional.ofNullable处理前端传入的模糊查询变量判空实战

处理前端传来的模糊查询参数时，比如姓名、手机号、状态这些字段，经常遇到的一个尴尬局面是：参数要么是 null，要么是空字符串，甚至是一串看不见的空白字符。如果直接用这些值去拼接 SQL，轻则查不出正确结果，重则导致全表扫描，性能直接崩掉。

很多同学的第一反应是用 if 判断堆一长串，比如 if (str != null && !str.trim().isEmpty())。这种写法本身没错，但问题是它散落在代码各个角落，容易漏掉 trim()，也容易忽略前后空格对 like 查询的干扰。久而久之，重复劳动多，维护起来也头疼。

其实，Ja va 8 引入的 Optional.ofNullable 正好可以优雅地解决这个问题。它不是为了炫技，而是把“判空 + 默认值 + 安全调用”这三步逻辑收束在一起，让代码清晰得就像一条流水线。

一个典型场景：将前端 name 参数转为 SQL 的 %name% 模式

假设 Controller 接收一个 @RequestParam String name，我们希望做到以下几点：

• 如果 name 是 null 或纯空白（比如全角空格、制表符、换行符），就忽略这个查询条件，不让它参与 where 子句。
• 如果 name 确实有实际内容，比如“张”，就转成“%张%”用于 like 匹配。
• 避免因为空字符串导致 SQL 中间出现 like '%%' 这种扫全表的操作。

对应代码可以这样写：

String likeName = Optional.ofNullable(name)
    .map(String::trim)
    .filter(s -> !s.isEmpty())
    .map(s -> "%" + s + "%")
    .orElse(null);

你看，这行代码把“取值 → 去空格 → 判有效 → 转 like 模式”串成了一条语义流，读起来很自然，也不容易遗漏某个步骤。后续在 MyBatis 或 JPA 中，就能安全地判断：if (likeName != null) { criteria.add(Restrictions.like("name", likeName)); }，清爽多了。

扩展用法：多个模糊字段统一处理

当你的查询条件里同时有 name、phone、email 等多个可选模糊字段时，重复写类似的 Optional 链会有点冗余。这时候可以封装一个工具方法，复用逻辑：

public static String toLikePattern(String raw) {
    return Optional.ofNullable(raw)
            .map(String::trim)
            .filter(s -> !s.isEmpty())
            .map(s -> "%" + s + "%")
            .orElse(null);
}

然后在 service 层直接调用：

• query.setNameLike(toLikePattern(request.getName()));
• query.setPhoneLike(toLikePattern(request.getPhone()));
• query.setEmailLike(toLikePattern(request.getEmail()));

这样既保持了判空逻辑的一致性，又不污染业务主流程。代码看起来干净、统一，后续要调整判空规则（比如要不要忽略特定字符）也只需改一个地方。

注意边界：Optional 不能替代数据库层的空值语义

这里必须强调一点：Optional.ofNullable 解决的是 Ja va 层入参的“是否参与查询”问题，而不是让数据库字段变非空。两者完全是两码事。

• 前端传了空字符串，你通过 Optional 转成 null → 查询时这个条件被跳过，这是合理的。
• 但若数据库中 name 字段存了空字符串 ""，它和 NULL 是两回事，like "%...%" 依然能匹配到 ""。这一点需要在数据建模和清洗阶段就明确清楚。
• 不要指望用 Optional 把 "" 自动变成 NULL 再写进数据库——那是 DTO 转 Entity 或 MyBatis 的 TypeHandler 该管的事。

说得直白点，Optional 是帮你守住代码入口，不是替你管住数据底座。入口干净了，后面的查询逻辑才能稳定可靠。