配置缺失必须用orelsethrow，因其语义精准表达“无值即非法状态”，避免默认兜底导致静默失败，且异常堆栈直指源头；需用lambda延迟构造带上下文的自定义异常，禁用提前拼接或副作用逻辑。
关键配置变量缺失不是“可能出错”，而是“必须报错”。用 orElseThrow 能让这种业务契约一目了然，不绕弯、不兜底、不掩盖问题。
为什么配置缺失必须用 orElseThrow，而不是 orElse 或 ifPresent
配置项（如数据库连接串、密钥、超时阈值）通常属于系统启动或核心流程的前置依赖。它的缺失不是可恢复的业务分支，而是非法状态。
-
不用
orElse("default")：配置没有“默认值”——硬编码一个假 URL 或空 token 可能导致后续静默失败，排查成本远高于立即报错 -
不用
if (opt.isPresent()) {...} else {throw...}：多一次判空调用，且破坏链式表达；若配置从外部加载（如 Spring Environment），两次调用间存在竞态风险 -
必须用
orElseThrow：语义精准——“此处无值，流程不可继续”，异常堆栈直接指向配置读取点，便于定位源头
正确构造自定义异常，避免提前执行副作用
配置名、环境标识、上下文路径等信息必须动态拼接，且仅在缺失时才计算。
-
✅ 推荐写法：
config.get("db.url").orElseThrow(() -> new ConfigMissingException("DB_URL not found in " + env.getActiveProfiles()[0])) -
❌ 错误写法：
String msg = "DB_URL not found in " + env.getActiveProfiles()[0]; config.get("db.url").orElseThrow(() -> new ConfigMissingException(msg))（msg 提前拼接，即使配置存在也会执行） -
⚠️ 隐蔽陷阱：
orElseThrow(() -> { log.warn("loading fallback config"); return new ConfigMissingException(); })（日志总打印，干扰监控）
嵌套配置读取中的链式 orElseThrow
真实配置常有层级结构，比如 app.redis.host → app.redis.port → app.redis.timeout。可逐层断言，每层抛对应异常。
- 先取顶层 Optional：
Optional<string> redisSection = config.get("app.redis")</string> - 再链式提取子项：
redisSection.map(s -> config.get(s + ".host")) .flatMap(Function.identity()) .orElseThrow(() -> new ConfigMissingException("redis.host missing")) - 优势：异常消息可精确到字段级，不依赖 try-catch 包裹整段逻辑
与 Spring Boot 的 @Value + @ConfigurationProperties 对比
Spring 原生方案适合简单场景，但缺乏运行时动态校验能力：
- @Value("${db.url:}") 若未配，返回空字符串，后续仍需手动判空 throw
- @ConfigurationProperties 绑定失败会抛
BindException，但错误信息泛化，不易区分是格式错还是根本没配 - 用
Optional+orElseThrow是主动防御：在你真正需要那个值的那一刻，用最短路径抛出带业务语义的异常
