自研框架引入Optional是为用类型系统显式暴露空值风险，强制接口返回Optional<T>、禁用反模式操作、自动封装各层空值场景，并通过可观测机制闭环治理。
在自研框架中引入 Optional 不是为了让代码看起来更“函数式”，而是用类型系统主动暴露空值盲区，把“可能为空”从隐式假设变成显式契约。
强制暴露空值路径
开发人员常写 user.getName() 却不检查 user 是否为 null，问题不在调用处，而在返回处——方法签名没说清“可能没有用户”。自研框架应在关键接口层统一返回 Optional<User>，而非 User。这样：
- 调用方无法直接解引用，必须显式处理
isPresent()、orElse()或ifPresent() - IDE 和静态分析工具能识别未处理的
Optional，提前标红警告 - 单元测试覆盖率统计会自然覆盖空分支，避免“以为测了其实没测”
拦截非安全构造与误用
仅返回 Optional 不够，开发者仍可能写出 Optional.of(null) 或 optional.get() 这类反模式。框架需内置防护：
- 提供受控工厂方法（如
Optional.safeOf(user)），内部校验非空再包装 - 在构建时禁用原始
Optional.of()，通过编译期注解（如@RestrictedApi）或字节码插桩拦截 - 对
.get()调用插入运行时断言，开发环境抛异常并打印调用栈，倒逼改用安全替代方案
贯穿上下文生命周期
空值风险不止在单个对象，更藏在链式调用和跨层传递中。框架应支持：
- 数据库查询结果自动封装为
Optional（如 MyBatis 插件拦截selectOne方法） - HTTP 响应体解析器将 404/空响应映射为
Optional.empty()，而非抛异常或返回 null - 配置中心客户端对缺失 key 返回
Optional.absent()，避免 fallback 逻辑被跳过
配套可观测与反馈机制
防御策略要闭环才有持续效力。框架可记录两类信号：
- 高频调用
orElse(null)的位置——说明业务逻辑仍默认“应该有”，需推动领域建模修正 - 未处理
Optional就直接丢弃的链路（如日志埋点中只取.map(User::getId).orElse(null)后不再判断）——暴露监控盲区
这些数据接入内部质量看板，比单纯写规范更有驱动力。
