Optional.of仅接受非null值，否则抛NullPointerException；ofNullable才适用于可能为null的场景，如外部输入、数据库查询等，应避免在未判空时误用of。
Optional.of 只接受非 null 值，传入 null 会直接抛 NullPointerException —— 这是它最核心的约束，也是最容易踩坑的地方。
明确区分 of 和 ofNullable 的用途
Optional.of 的设计意图就是“我确定这个值不为 null”，它不负责判空，也不做兜底。如果你还不确定值是否为空，就别用它。
- 用
Optional.of(obj)：仅当obj != null是你代码逻辑中绝对成立的前提（比如刚 new 出来的对象、已校验过的参数） - 用
Optional.ofNullable(obj)：适用于任何可能为 null 的场景，安全返回Optional.empty()
别在不确定来源的数据上硬套 of
常见反模式：从 HTTP 请求、数据库查询、配置读取、JSON 解析等外部来源拿到对象后，没做判空就直接 Optional.of(value)。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 例如：
String name = request.getParameter("name"); Optional.of(name)—— 若参数未传，name为 null，立刻崩溃 - 正确做法：
Optional.ofNullable(name)，后续再用filter、map或orElse处理空逻辑
方法参数校验后才考虑 of
如果你在私有方法或内部逻辑中，已经通过 if 判空或断言确保了值非空，这时用 of 是合理且清晰的语义表达。
立即学习“Java免费学习笔记（深入）”；
- 例如：
if (user == null) throw new IllegalArgumentException("user must not be null"); return Optional.of(user); - 此时
of不是“省代码”，而是向调用方传递该值必然存在的契约信号
警惕链式调用中隐藏的 null
容易忽略的是：即使前一步用了 ofNullable，中间 map 或 flatMap 返回的函数体里若产生 null，再用 of 就又危险了。
- 错误示例：
Optional.ofNullable(user).map(User::getProfile).map(p -> Optional.of(p.getName()))—— 若p.getName()返回 null，of仍会炸 - 应改为：
Optional.ofNullable(user).map(User::getProfile).map(Profile::getName).map(Optional::of)不行，还是错；正确是去掉内层of，让整个链保持 Optional 上下文
