Java的of()系列方法强制拒绝null，是硬性契约而非建议；可作入参校验器，配合@NotNull注解和不可变容器设计，构建编译期与运行期双重空安全防线。

Java 的 List.of()、Set.of()、Map.of() 等不可变集合工厂方法，从设计上就拒绝 null——这不是建议，而是硬性契约。一旦传入 null，立刻抛出 NullPointerException，且堆栈指向调用点，不进深层逻辑。这本身就是一道天然的「入参红线」，关键在于如何把它用成真正可靠的安全防线。

把 of 方法当「校验器」用，而非仅当容器创建工具

很多人只把 List.of(a, b, c) 当作快捷写法，却忽略它自带的空值拦截能力。只要参数里有 null，运行时直接失败，比手写 if (x == null) 更早暴露问题。

• 适用于明确要求所有元素非空的场景：比如初始化配置项列表、构建枚举映射键值对、组装固定参数集合
• 不适用于需容忍部分空值的动态数据（如数据库查询结果），此时应先过滤或转为 Optional 处理
• 错误示范：List.of(user.getName(), user.getEmail(), user.getPhone()) —— 若任一字段为 null，立即炸；正确做法是先校验或使用安全包装

配合 @NotNull + 编译期检查，把红线前移到编码阶段

@NotNull 注解（来自 javax.validation.constraints 或 JetBrains）本身不运行，但和 IDE、Lombok、构建插件联动后，能提前标出风险。

• 在方法参数上标注 @NotNull List names，IDE 会提示你传 List.of(...) 是安全的，而传 Arrays.asList(null, "b") 会预警
• Lombok 的 @RequiredArgsConstructor 配合 @NonNull 字段，自动生成 Objects.requireNonNull，与 of() 的空值拦截形成双重保障
• 注意：of() 拦的是集合元素，@NotNull 拦的是集合引用本身——两者互补，不重叠

用 of() 构建不可变入参容器，切断外部篡改路径

接收可变集合（如 ArrayList）作为参数，意味着调用方可能在你处理中途修改它；而用 of() 创建的集合天生不可变，也天然不含 null。

• 推荐接口定义：void processRoles(List roles) → 改为 void processRoles(List roles)，并在实现开头加 roles = List.copyOf(roles) 或直接要求传 List.of(...)
• 若必须接受外部集合，优先转为不可变副本：List.copyOf(inputList)（JDK 10+）会做空值检查并复制，比 Collections.unmodifiableList 更安全
• 禁止将 of() 结果再转回可变类型（如 new ArrayList(List.of(...))），否则失去防线意义

警惕「假安全」组合：of() 和 null 元素共存的常见破防点

of() 的空值拦截非常严格，但开发者常因疏忽绕过它：

• 误用 Arrays.asList(null) 后再传给 of()：错！Arrays.asList 允许 null，of() 才真正拦截，但此时已晚一步
• 用 stream().collect(Collectors.toList()) 聚合含 null 的流，再喂给 of()：同样失效，需先 filter(Objects::nonNull)
• Map 场景更隐蔽：Map.of(key, null) 直接报错，但 Map.ofEntries(entry1, entry2) 中某个 entry.getValue() 为 null 也会触发异常