Optional 是将“值可能存在或不存在”语义显式建模为对象，实现空值处理的语义升维与面向对象落地，仅应作为方法返回类型使用。
optional 不是“避免判空的语法糖”，而是把“值可能存在或不存在”这个语义显式建模为一个对象——它本身就是面向对象思想在空值场景下的自然落地。
用 Optional 替代裸 null，完成语义升维
传统写法中，null 是一个特殊值，既不是对象，也不具备行为，却要承担“缺失”的语义。这违背了 OOP 的核心原则：一切应通过对象交互表达意图。Optional 把“可能为空”封装成一个真实对象，让调用方不再面对模糊的 null，而是与一个有明确定义、可组合、可扩展的容器交互。
- 返回
Optional<user></user>比返回User更准确：它声明了“这里可能查不到用户”，而非隐含“查不到就给你 null，你自己看着办” - 方法签名即契约：
public Optional<order> findOrder(String id)</order>让调用者从第一眼就知道需处理“未命中”分支，无需翻文档或猜逻辑 - 避免下游误用：
user.getAddress().getCity()在user为 null 时崩溃；而optionalUser.map(User::getAddress).map(Address::getCity).orElse("未知")整条链天然免疫空指针
链式操作即对象协作，不是语法技巧
Optional 的 map、flatMap、filter 等方法，本质是对象间的消息传递与委托协作，完全符合 OOP 的“ Tell, don’t ask” 原则——你告诉它“我要取城市名”，而不是先问“你有没有地址？地址有没有城市？”再自己一步步取。
-
map：当前 Optional 有值时，将值交给函数转换；无值时静默跳过——这是对象内部状态驱动的行为，不是外部 if 判断 -
flatMap：当转换结果本身也是 Optional（如address -> Optional.ofNullable(address.getCity())），它自动展平嵌套，避免Optional<optional>></optional>这种反模式 -
filter：不是“过滤集合”，而是对 Optional 内部值做断言；满足条件保留原值，不满足则转为空 Optional——仍是对象自治决策
结合构造与策略，构建可演进的空值模型
Optional 可与工厂、策略等 OOP 模式协同，让空值处理从“临时补丁”升级为可配置、可替换的业务能力。
- 用
orElseGet(Supplier)延迟加载默认值：比如查不到用户时，调用FallbackUserService::createGuestUser创建游客对象，而不是硬编码一个匿名用户 - 配合 Spring 条件化注入：定义
@Primary @ConditionalOnMissingBean UserResolver的空实现类，当业务未提供具体解析器时自动启用兜底策略 - 与空对象模式互补：Optional 适合“一次性的值获取与转换”，空对象适合“长期持有的协作角色”。例如，
Optional.ofNullable(paymentGateway).orElse(NullPaymentGateway.instance())，既保证非空引用，又保留明确语义
警惕滥用：Optional 不是万能容器
Optional 的设计初衷是作为**方法返回类型**，用于表达“计算结果可能不存在”。它不适合出现在字段、参数或集合中，否则会破坏封装性并增加理解成本。
- ❌ 错误：在实体类里声明
private Optional<string> name;</string>—— 这让对象自身状态变得模糊，且序列化、ORM 映射都易出问题 - ❌ 错误：方法参数写成
void process(Optional<user> user)</user>—— 调用方仍需包装，反而增加调用负担 - ✅ 正确：只在返回值中使用，如
Optional<product> findById(Long id)</product>、Optional<bigdecimal> getDiscountRate()</bigdecimal>
