直接调用 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 检查器，阻断构建

不复杂但容易忽略。