orElseThrow()用于显式表达“配置必须存在”的业务契约，仅适用于强依赖、不可降级的核心配置（如支付网关地址、限流规则ID等），需通过Lambda延迟构造异常并携带上下文信息，结合配置初始化阶段校验与监控实现可观测性。
当配置项缺失时，直接用 get() 或硬编码默认值，容易掩盖问题、导致行为不一致，甚至引发线上故障。用 orElseThrow() 不是“加个异常就完事”，而是把“配置必须存在”这个业务契约显式表达出来，让缺失立刻暴露、精准定位、可控兜底。
明确哪些配置适合用 orElseThrow
不是所有配置都该炸——只对强依赖、不可降级、影响主流程正确性的配置启用它：
- 支付网关地址、密钥、回调超时时间（缺一则无法完成支付）
- 核心限流规则 ID、熔断开关标识（缺则策略失效，可能引发雪崩）
- 多租户场景下的默认租户编码（缺则用户无法归属，后续鉴权全错）
- 数据库分库分表路由策略名（缺则 SQL 路由失败，查不到数据或写错库）
正确构造 Supplier，避免副作用提前触发
关键在“懒加载”：异常对象和日志、监控等副作用，必须只在配置真为空时才执行。
- ✅ 正确：用 Lambda 延迟构造，含上下文信息
featureToggleProperties.getTimeoutMs().orElseThrow(() -> {<br> log.error("Critical config 'app.timeout.ms' missing for service: {}", serviceName);<br> throw new ConfigMissingException("Timeout configuration not found");<br>}); - ❌ 错误：日志在 Optional 创建时就打印（即使配置存在）
featureToggleProperties.getTimeoutMs().orElseThrow(() -> {<br> log.warn("timeout config missing"); // 每次都执行！<br> return new RuntimeException();<br>}); - ⚠️ 隐患：传入方法引用但无参，无法带变量
.orElseThrow(ConfigMissingException::new) // 只能用无参构造，丢失 key 和 service 信息
与配置加载生命周期结合，提升可观测性
别等到运行时才报错。把 orElseThrow() 放在配置初始化阶段（如 @PostConstruct 或 @Bean 方法中），配合 Spring Boot 的 @ConfigurationProperties 绑定验证：
- 在 Bean 创建时校验必配项，启动失败快反馈，避免服务上线后静默异常
- 异常消息里带上配置路径（如
app.payment.gateway.url）、环境（profile=prod）、生效位置（via application.yml），方便运维快速排查 - 搭配 Micrometer 打点：
config.missing.count{key="app.payment.gateway.url",env="prod"}，监控配置缺失趋势
避免和 ifPresent + throw 混用
有人写：if (!optional.isPresent()) throw new ConfigMissingException(...); return optional.get(); —— 这有竞态风险且冗余。
-
isPresent()和get()是两次调用，中间若被并发修改（极少见但非零概率），get()仍会抛NoSuchElementException -
orElseThrow()是原子操作，语义清晰，一行到位，且编译器能更好优化 - 若需在“有值时也做校验”（如值为负数也非法），应先
filter再orElseThrow：props.getRetryCount().filter(n -> n > 0).orElseThrow(() -> new InvalidConfigException("retry count must be positive"));
