方法引用本身不提供空安全，关键在于配合@NonNull注解、编译期检查与类型系统约束形成强类型契约；需通过静态分析工具、专用非空函数式接口及安全封装（如safeRef）在编译阶段拦截不合规引用，杜绝运行时NPE。
方法引用本身不提供空安全，它只是对已有方法的快捷绑定；真正起作用的是配合可空性注解、编译期检查和类型系统约束形成的“强类型契约”。在中大型团队项目中，消除隐式空指针的关键不是避免写::，而是让方法引用所指向的目标方法及其参数/返回值，在编译阶段就拒绝空值参与调用链。
用 @NonNull 注解锁定方法引用的入参与返回值
当一个方法被标记为接收非空参数或返回非空结果时，任何将其作为方法引用使用的场景（如 list.forEach(User::getName)）都会在编译器静态分析中触发警告——如果 User 可能为 null，则该引用不合法。
- 在接口或工具类中统一使用
@NonNull标注关键方法： public static @NonNull String formatName(@NonNull User user) { ... } - 启用 Java 的可空性检查（如 Lombok 的
@NonNull+ IDE 静态分析，或 Spring 的@NonNullApi），使User::formatName在user类型未声明为非空时无法通过编译 - 避免在 lambda 中手动判空再调用，改为把判空逻辑下沉到被引用的方法内部，让方法引用天然具备空安全语义
结合 Optional 构建可组合的空安全方法引用链
原始对象引用（如 List<User>）若允许含 null 元素，直接用 :: 会隐式崩溃。应先用 Optional 封装源头，再构造方法引用。
- 不安全写法：
users.stream().map(User::getEmail).collect(...)—— 若某User为null，运行时报 NPE - 安全写法：
users.stream().map(Optional::ofNullable).map(opt -> opt.map(User::getEmail).orElse(null)).collect(...) - 更优实践：定义工具方法
static <T,R> Function<T, R> safeRef(Function<T,R> f) { return t -> t == null ? null : f.apply(t); }，然后写成safeRef(User::getEmail)
在函数式接口定义中强制非空语义
团队共用的函数式接口不应接受任意 Function<T,R>，而应定义专用接口并标注泛型约束。
- 定义：
interface NonNullFunction<@NonNull T, @NonNull R> extends Function<T,R> {} - 所有业务模块注册处理器时，必须传入实现该接口的实例，IDE 和编译器会校验
::绑定的方法是否满足参数/返回值非空 - 配合 Spring 的
@FunctionalBean或自定义注解处理器，可在构建期拦截不合规的方法引用注册
利用 IDE 与构建插件自动拦截不安全引用
方法引用的空风险往往在重构后暴露（如原方法加了 @Nullable 但调用处未更新）。需靠工程化手段守住底线。
- 在 Maven/Gradle 中启用
errorprone或NullAway插件，它们能识别list.forEach(obj::method)中obj是否可能为空，并报错而非警告 - 配置 IntelliJ 的 Inspection：启用 “Method reference may cause NullPointerException”，并设为 Error 级别
- 在 CI 流程中加入字节码扫描步骤，检测
INVOKEVIRTUAL前是否有空值校验，对无防护的方法引用提交直接拒绝合并
