optional.ofnullable用于安全包装可能为null的配置值，通过orelse/orelseget/orelsethrow提供降级策略，避免npe；需配合filter校验空字符串、orelseget实现动态逻辑，但不解决配置加载失败等根本问题。
用 Optional.ofNullable 处理外部配置变量，核心是把“可能为 null”的配置值包装成 Optional，再用 orElse、orElseGet 或 orElseThrow 安全地提供降级策略。它不解决配置加载本身，而是让取值逻辑更清晰、更不易出 NPE。
避免直接调用 get()，优先用 orElse/orElseGet
从配置中心或 Properties 中读取字符串时，常见写法是：
String timeout = config.getProperty("http.timeout");int timeoutMs = timeout != null ? Integer.parseInt(timeout) : 3000;
用 Optional 改写后更健壮：
int timeoutMs = Optional.ofNullable(config.getProperty("http.timeout")).map(Integer::parseInt)
.orElse(3000);
注意：如果配置值是空字符串（""）或非数字，map(Integer::parseInt) 会抛 NumberFormatException —— 这属于业务校验范畴，Optional 不负责兜底类型错误。建议在 map 前先 filter 非空且匹配数字格式，或改用 orElseGet 延迟计算：
-
orElse(3000)：立即执行，适合简单字面量默认值 -
orElseGet(() -> loadFromBackupConfig())：仅在为空时调用，适合开销大或需 IO 的降级逻辑
链式解析嵌套配置，减少 if 判空
比如 YAML 中有 database.pool.max-active: 20，传统方式要逐层判空：
return config.getDatabase().getPool().getMaxActive();
} else {
return 10;
}
用 Optional 链式调用更简洁：
int maxActive = Optional.ofNullable(config.getDatabase()).map(Config::getPool)
.map(PoolConfig::getMaxActive)
.orElse(10);
每一步 map 都天然跳过 null，无需显式 if。若某层为 null，整个链自动短路，最终走 orElse。
配合 Supplier 实现动态默认值和日志告警
降级不只填个数字，有时需要记录“用了默认值”这个事实。用 orElseGet 可同时做两件事：
.filter(key -> !key.trim().isEmpty())
.orElseGet(() -> {
log.warn("api.key not found, using mock key for dev");
return "mock-api-key-123";
});
关键点：
-
filter排除空字符串、纯空白等“逻辑空值”，比仅判 null 更严谨 -
orElseGet内部可写任意 Java 逻辑：打日志、发监控、查备用配置源 - 不要在 orElseGet 里 throw 异常（那是 orElseThrow 的职责）
不适用场景：配置加载失败本身需强管控
Optional 适合处理“配置存在但值为 null/空”，不适合替代配置加载机制。例如：
- 配置中心连接失败 → 应抛 Checked Exception 或启动失败，不该靠 Optional 降级
- 必填配置项缺失（如数据库 URL）→ 应 early fail，而不是默默给一个假的 "jdbc:h2:mem:test"
- 环境差异导致 key 名不同（如 dev.key vs prod.key）→ 应统一配置命名规范或用 Profile 分离，而非靠 orElse 补救
Optional 是“值安全访问”的工具，不是配置治理方案。它让降级逻辑显性、可控、可测，但不能掩盖设计缺陷。
