Optional 应仅作为可能无结果的查询方法返回值，不得用于参数、字段或构造器；非空方法不应包装Optional，创建时须用ofNullable而非of(null)。
Java 中 Optional 作为方法返回值，核心目标是显式表达“可能无结果”这一语义，而不是用来包装任意可空值。设计是否规范，关键看是否契合它的原始定位：它是 API 设计层面的契约工具，不是空值处理的万能胶。
只用于明确“可能无结果”的查询类方法
这是最核心的规范。Optional 应出现在调用方合理预期可能得不到值的场景中，比如根据唯一标识查找单个资源：
- 数据库按 ID 查询：public Optional
findById(Long id) - 缓存中获取：public Optional
getCachedProduct(String sku) - 配置项读取（非必需）：public Optional
getOptionalFeatureFlag(String key)
反例：计算方法、转换方法、构造方法等本不该失败或本应总有结果的，不应返回 Optional。例如 public Optional
不包装已知非空或必然存在的值
如果方法逻辑上保证一定有返回值，强行套一层 Optional 不仅冗余，还会误导调用方以为需要处理空值：
立即学习“Java免费学习笔记（深入）”；
- ❌ 错误：public Optional
getConstantVersion() { return Optional.of("1.2.0"); } - ✅ 正确：public String getConstantVersion() { return "1.2.0"; }
同理，不要用 Optional.of() 包装一个你刚从非空校验（如 Objects.requireNonNull）得到的对象——那只是徒增开销和混淆意图。
避免在参数、字段、构造器中使用 Optional
Optional 的设计初衷是仅作返回值类型，官方明确不推荐其他用途：
- 禁止作为方法参数：public void process(Optional
input) —— 调用方还得自己包装，丧失语义清晰性 - 禁止作为 Bean 字段：private Optional
email; —— Optional 不可序列化，破坏 JSON/XML 传输与持久化 - 禁止作为构造器参数：public Person(String name, Optional
nickname) —— 把简单可选字段复杂化，且无法区分“传了 null”和“传了 Optional.empty()”
这些位置该用普通类型 + 文档说明可空性，或用 @Nullable 注解更合适。
返回前确保值确实可能为空，且优先用 ofNullable
一旦决定返回 Optional，创建时要诚实反映底层逻辑：
- 如果来源本身可能为 null（比如 DAO 返回 User 对象），直接用 Optional.ofNullable(user)
- 避免先判空再手动构造：if (user != null) return Optional.of(user); else return Optional.empty(); —— ofNullable 一行就搞定
- 绝对不用 Optional.of(null)，这会立刻抛出 NullPointerException，失去防护意义
这样既简洁，又准确传达“这个 null 是业务允许的缺失，不是程序 bug”。
不复杂但容易忽略
