Java Optional规范明确三必用场景（主键查询、外部可选值读取、链式依赖缺失）、四禁令（禁字段/参数/Controller返回/get调用），并统一ifPresent/orElse/orElseThrow等用法及命名习惯。
团队制定 Java Optional 代码规范，核心是统一认知、明确边界、聚焦实效，避免“为用而用”或“不敢用”。规范不是越细越好，而是要解决真实协作中的歧义和风险。
明确哪些场景必须用 Optional
只在方法返回值中使用，且仅限以下三类明确语义的场景：
- 数据库/缓存按主键查询单条记录（如
Optional<user> findById(Long id)</user>） - 配置项、环境变量等外部可选值读取（如
Optional<string> getConfig(String key)</string>） - 链式依赖中某环节天然可能缺失（如
user.getAddress().flatMap(Address::getCity)）
其他情况——比如普通业务逻辑中间变量、DTO 字段、HTTP 请求参数解析结果——一律不强制包装 Optional。
划清四条硬性禁令
这些是团队 Review 时一票否决项，写进 Confluence 或 Git 提交检查（CI Hook）：
立即学习“Java免费学习笔记（深入）”；
- 禁止作为类字段或 Bean 属性类型：Optional 不可序列化，会破坏 RPC、JSON 序列化、MyBatis 映射等基础能力
-
禁止作为方法参数：调用方传
Optional.empty()或null意图模糊，增加理解成本 - 禁止在 Controller 层直接返回 Optional：Spring MVC 不原生支持 Optional 响应体，易引发空响应或 500 错误
-
禁止调用 get()：它等于放弃 Optional 的设计价值，和裸写
obj.getXXX()无异；CI 可用 SonarQube 规则拦截
统一常用模式与命名习惯
减少“同一件事五种写法”，提升可读性：
- 存在即处理 → 用
ifPresent()，不写isPresent() + get() - 需要默认值 → 简单字面量用
orElse("default")，复杂计算用orElseGet(this::loadDefault) - 不存在即报错 → 统一用
orElseThrow(() -> new XxxException("xxx"))，异常类型需提前约定（如ResourceNotFoundException） - 方法命名保持一致：返回 Optional 的方法名不加
Opt或Nullable后缀（如findUser()而非findUserOpt()），靠返回类型自解释
配套落地动作
规范生效关键在“有人盯、有工具卡、有例子学”：
- 在团队共享文档中附 3 个正例 + 3 个反例（含错误堆栈截图）
- 在 IDE 模板（Live Template）中预置常用 Optional 链式写法片段，如
opt.map(...).filter(...).orElse(...) - 新成员 onboarding 时，用一段含嵌套 null 判断的老代码，现场重构为 Optional 链式调用，直观感受差异
- Code Review Checklist 第一条即：“是否违反 Optional 四禁令？是否符合三必用场景？”
