直接调用 Optional.get() 是最危险的反模式，应仅在100%确定值存在时使用；替代方案包括orElse、orElseThrow、ifPresent及map链式操作，并从设计源头杜绝滥用。
直接调用 optional.get() 是最危险也最普遍的反模式——它把原本想规避的 nullpointerexception 换成了 nosuchelementexception，既没提升安全性，又掩盖了空值语义。纠正的关键不是“少用 get”，而是用对语义、选对替代方法。
明确 get() 的适用边界
get() 唯一合理场景是：你**100%确定值必然存在**，且该确定性来自逻辑约束（而非运行时猜测）。例如：
- 经
isPresent()判定为 true 后立即调用（但此时更推荐ifPresent） - 由
Optional.of(...)创建的实例（因构造时已强制非 null） - 测试中用于断言“这个 Optional 必须有值”
凡涉及外部输入、数据库查询、网络响应等不确定来源，get() 就不该出现。
按业务意图选择安全替代方案
不要机械替换，要匹配真实需求：
-
需要默认值 → 用
orElse("default")（简单值）或orElseGet(() -> computeDefault())（开销大时延迟计算） -
需要抛异常且带业务含义 → 用
orElseThrow(() -> new UserNotFoundException("ID: " + id))，比裸get()更可读、更易定位问题 -
只在有值时执行副作用 → 用
ifPresent(user -> sendWelcomeEmail(user))，避免 if+get 的冗余判断 -
需链式转换后取值 → 用
map(...).filter(...).orElse(...)，保持函数式风格，不中断流式处理
从源头杜绝 get() 的生存土壤
很多 get() 调用，本质是方法设计不合理：
- 检查是否将
Optional当参数传递？应改为允许null入参，返回值才用Optional - 是否在循环或高频路径中创建大量
Optional？考虑是否真需要包装——简单判空用Objects.nonNull()更轻量 - 团队是否缺乏统一规范？建议在代码审查清单中加入“禁止无条件 get()”，并用 SonarQube 或自定义 Checkstyle 规则自动拦截
用工具辅助识别和修复
静态分析能快速定位隐患：
- IDEA 默认高亮
get()调用，并提示“Unsafe call to ‘get()’” - 启用
-Xlint:optional（JDK 17+）编译时警告潜在误用 - 在 CI 流程中集成
error-prone，启用OptionalGet检查器，阻断构建
不复杂但容易忽略。
