Optional封装临时变量的核心是显式表达“值是否存在”，而非缓存；它通过isPresent()、or()等方法实现状态可见、短路计算与线性决策链，避免null判断、布尔标记和嵌套分支。
用 Optional 封装系统临时变量，核心不是“缓存中间值”，而是把“该变量是否已计算/是否有效”这个状态显式暴露出来，避免长方法里靠一堆布尔标记或 null 判断来管理生命周期。它让临时值的“存在性”成为第一等语义，而不是藏在 if 分支或注释里。
用 Optional 声明临时变量，替代 null 或未初始化字段
在长方法中，常有类似“先查缓存，没命中再查 DB，最后 fallback 到默认值”的逻辑。若用普通变量，容易出现：
- 变量声明后未赋值，后续误用（编译不报错但运行 NPE）
- 靠 boolean isCached = false; 配合 if-else 管理状态，逻辑分散
- 多个临时值之间依赖关系模糊，难以追踪“谁该被用、谁还没算”
改用 Optional 可自然表达“尚未产生”或“已生成但可能无效”：
Optional<User> cachedUser = Optional.empty(); Optional<User> dbUser = Optional.empty(); Optional<User> fallbackUser = Optional.empty();
每一步操作后直接赋值，无需额外 flag；后续用 isPresent() 或链式方法即可判断状态，语义清晰、不可绕过。
按需计算 + 短路传播，避免冗余执行
临时变量往往涉及代价较高的操作（如远程调用、IO、复杂解析）。用 Optional 结合 orElseGet() 可实现“只在真正需要时才计算”：
- 先尝试从本地缓存获取：
cachedUser = Optional.ofNullable(cache.get(userId)); - 仅当缓存为空时，才触发 DB 查询：
dbUser = cachedUser.or(() -> Optional.ofNullable(userMapper.selectById(userId))); - fallback 同理：
fallbackUser = dbUser.or(() -> loadDefaultUser());
注意：这里用的是 or(Supplier<Optional<T>>)（Java 9+），它只在当前 Optional 为空时才执行 supplier，天然支持短路和延迟计算。比写 if-else 更紧凑、更函数化。
组合多个临时结果，构建可读的决策链
当长方法需要综合多个临时变量做最终决策（比如“优先用缓存，其次用 DB，最后用配置默认值，三者都无则报错”），可用 flatMap + orElseThrow 构建线性流程：
User finalUser = cachedUser
.or(() -> dbUser)
.or(() -> fallbackUser)
.orElseThrow(() -> new IllegalStateException("User not available from any source"));
整条链清晰表达了“尝试顺序”和“失败兜底”，没有嵌套、没有重复判空、没有中间变量污染作用域。每个环节返回 Optional，空值自动跳过，语义即实现。
不建议的用法：避免把 Optional 当成“万能占位符”
以下做法会削弱 Optional 的价值，应避开：
- 声明为类字段（如
private Optional<String> tempToken;）—— 它不是状态容器，而是单次计算结果的封装 - 在循环内反复 new Optional.empty() —— 不必要开销，且掩盖了“为何需要多次重置”的设计问题
- 用 get() 强取值而不检查 —— 一旦漏掉，就退回 NPE 地狱
临时变量的 Optional 封装，本质是把“计算过程的状态”转为“值的存在性”，让长方法的控制流更扁平、更可推导、更难出错。
