ifPresentOrElse 实现完备双向路由，要求“有值”和“无值”均为语义对等、职责明确、不可省略的主动业务路径，强制逻辑闭环，杜绝忽略空分支；空分支需独立执行、避免NPE、不嵌套判空，且仅适用于无返回值的双向副作用操作。
用 ifpresentorelse 实现判空分支流的“完备双向路由”，核心在于把“有值”和“无值”真正当作两个**语义对等、职责明确、不可省略**的业务路径来设计，而不是一个主流程加一个兜底补丁。
双向路由 ≠ 有无判断，而是业务意图的对称表达
它强制你为两种状态都提供可执行动作，天然杜绝“只处理存在、忽略缺失”的盲区。关键不是语法多简洁，而是逻辑是否闭环：
- ✅ “用户配置存在 → 加载进运行时；不存在 → 初始化默认配置并持久化到 DB”——两边都是主动行为，有明确业务动因
- ❌ “用户存在 → 发欢迎邮件；不存在 → throw new RuntimeException()”——后者只是异常转嫁，没回答“这个空在当前上下文里意味着什么”
确保路由真正“完备”的三个实操要点
很多团队用了 ifPresentOrElse 却仍漏掉关键分支，问题常出在以下环节：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
空分支必须能独立执行：Runnable 不能依赖外部 null 变量（如
log.warn("id: " + id)中id本身为 null 就会 NPE），建议提前捕获或使用 Optional 包装上下文 -
不混淆“空值”和“空容器”：若上游返回的是
Optional.empty()，没问题；但若调用方传入的是null的 Optional 对象（非 empty），ifPresentOrElse会直接抛 NPE——务必先做Objects.requireNonNull(opt)或统一用Optional.ofNullable(opt).flatMap(Function.identity())安全解包 -
避免在 action 中再触发判空：比如
u -> { if (u.getProfile() != null) { ... } }，这违背了 Optional 链式防护的设计初衷；应改用flatMap(u -> Optional.ofNullable(u.getProfile()))把空值过滤下沉
典型双向路由场景与写法示例
这些例子体现“两边都做事”，且动作不可逆、有可观测性：
- 缓存读取：
cache.get(key).ifPresentOrElse(value -> serve(value), () -> triggerAsyncLoad(key))——命中即服务，未命中即触发异步加载（不是丢弃） - 设备指令下发：
deviceOpt.ifPresentOrElse(d -> pushCommand(d, cmd), () -> markOffline(deviceId))——在线则推指令，离线则标记状态并清理会话 - 支付回调处理：
orderOpt.ifPresentOrElse(o -> updateStatus(o, SUCCESS), () -> recordOrphanCallback(traceId))——订单存在则更新，不存在则归档为孤儿回调供人工核查
何时不该硬套 ifPresentOrElse
它只适用于“双向副作用操作”，不负责构造结果或做复杂决策：
- 需要返回值？→ 改用
map().orElseGet()或传统 if-else - 空分支要根据错误类型分不同处理（如网络超时 vs 数据库连接失败）？→ 它的 Runnable 不接收参数，无法区分原因，此时应退回到显式
isPresent()判断 - 要记录带堆栈的错误或重试？→ Runnable 不能抛受检异常，也不适合放重试逻辑，这类应交由上层异常处理器统一管理
