使用Optional.ofNullable可清晰统一处理前端模糊查询参数的判空、去空格和转like模式逻辑，避免因空值导致全表扫描，提升代码可读性与可维护性。
前端传来的模糊查询参数（比如姓名、手机号、状态等）经常是空字符串、null 或未传，直接用它们去查数据库容易出错或查出意外结果。用 Optional.ofNullable 不是为了炫技，而是把“判空 + 默认值 + 安全调用”这三步逻辑收束得更清晰、不易漏。
为什么不用 if (str != null && !str.trim().isEmpty())？
这种写法本身没错，但分散在各处易重复、易遗漏 trim、易忽略前后空格影响 like 查询；而 Optional.ofNullable 配合链式操作，能把“取值 → 去空格 → 判有效 → 转成 SQL like 模式”串成一条语义流，可读性和可维护性更高。
典型实战：将前端 name 参数转为 SQL 的 %name% 模式
假设 Controller 接收一个 @RequestParam String name，我们希望：
- 如果 name 是 null 或纯空白（如 " "、"\t\n"），就忽略该条件，不参与 where 查询
- 如果 name 有实际内容（如 "张"），就转成 "%张%" 用于 like 匹配
- 避免因空字符串导致 SQL 出现 like '%%' 全表扫
对应代码可这样写：
立即学习“前端免费学习笔记（深入）”；
String likeName = Optional.ofNullable(name)
.map(String::trim)
.filter(s -> !s.isEmpty())
.map(s -> "%" + s + "%")
.orElse(null);
后续 MyBatis 或 JPA 中就可以安全判断：if (likeName != null) { criteria.add(Restrictions.like("name", likeName)); }
扩展用法：多个模糊字段统一处理
当有 name、phone、email 等多个可选模糊字段时，可封装工具方法复用逻辑：
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 解决的是 Java 层入参的“是否参与查询”问题，不是让数据库字段变非空。例如：
- 前端传了空字符串，你转成 null → 查询时这个条件被跳过，合理
- 但若数据库中 name 字段存了空字符串 ""，它和 NULL 是两回事，
like "%...%"依然能匹配到 ""，这点需在数据建模和清洗阶段明确 - 不要指望用 Optional 把 "" 自动变成 NULL 再进库——那是 DTO → Entity 转换或 MyBatis TypeHandler 的事
说到底，Optional 是帮你守住入口，不是替你管住数据底座。
