应禁止Optional作为方法参数，仅限框架回调等极少数例外；通过编码规范明确禁用范围，Checkstyle自动拦截，提供重载、Builder、@RequestParam等替代方案，并在Code Review中强制检查。
不能靠“强制检查”来堵住 Optional 作参数的问题——它不是运行时校验工具，而是编译期语义容器。真正有效的做法是：用静态规则卡住源头、用团队约定统一认知、用代码审查聚焦高频风险点。
明确禁止场景并写入开发规范
在团队《Java 编码规范》中单列一条，清晰定义“Optional 禁止作为方法参数”的边界：
- 所有 public / protected 方法的形参类型不得为
Optional<T> - 构造函数、setter 方法、Controller 接口参数、DTO 字段均属禁用范围
- 例外仅限于极少数框架回调（如某些 Spring Data Repository 的自定义扩展），需额外评审并加 Javadoc 注释说明
用 Checkstyle 在构建阶段自动拦截
在 Maven 的 checkstyle.xml 中配置正则规则，让编译失败早于 Code Review：
- 禁止参数声明含
Optional<：<module name="ParameterName"><property name="format" value="^((?!Optional).)*$"/></module> - 禁止方法签名中出现
Optional<（覆盖构造器、setter）：<module name="Regexp"><property name="format" value="public|protected|private.*\bOptional<" /></module> - 配合 CI 流水线，确保未通过检查的 PR 无法合入主干
提供替代方案并统一模板
光禁止不够，要给出清晰、低心智负担的替代路径：
立即学习“Java免费学习笔记（深入）”；
- 非必填参数 → 用方法重载：
process(String data)和process(String data, String fallback) - 多选参数组合 → 封装为 Builder 或参数对象（POJO），字段保持原始类型
- Controller 层可选查询条件 → 用
@RequestParam(required = false)+ 原始类型，由 Controller 自行调用Optional.ofNullable()包装后传给 service - 内部 service 方法若需表达“可选行为”，用布尔标记或枚举代替，例如
process(data, ProcessingMode.SKIP_VALIDATION)
在 Code Review 中设为必查项
把“参数是否含 Optional”加入 Review Checklist，并配套轻量培训：
- 新人 onboarding 时演示错误写法与重构对比（比如
void update(Optional<user> user)</user>→void update(User user)+ 空值由调用方判断） - 定期扫描历史代码，对存量误用发起 refactor MR，不追求一步清零，但禁止新增
- Review 时直接引用规范条目（如“见编码规范 §3.2.1”），减少主观争议
