Collectors.toMap 要求 key 和 value 均不可为 null，JDK9+ 在内部校验中显式抛出 NPE；推荐方案依次为：预过滤 null、提供默认值、自定义 collector 或使用 merge 函数容错。
使用 Collectors.toMap 时，如果 value 为 null，会直接抛出 NullPointerException。这是因为 HashMap（toMap 默认使用的 Map 实现）不允许 null 值（除非显式指定支持 null 的 map 类型，但标准 toMap 不支持）。这不是 bug，而是设计限制，需主动规避。
理解 toMap 的 null 安全边界
Collectors.toMap 有三个常见重载方法，其中两个接受 BinaryOperator（用于处理 key 冲突），但**所有重载都要求 value 不能为 null**。源码中明确调用 map.put(key, value)，而 HashMap.put 在 value == null 时不报错，但 JDK9+ 的 toMap 实现内部使用了 Objects.requireNonNull(value) 校验 —— 这才是 NPE 的根源。
- JDK8 中部分场景可能“侥幸”通过（依赖 HashMap 行为），但不可靠
- JDK9 及以后严格校验 value 非空，NPE 成为确定行为
- key 为 null 同样不被允许，且校验更早（key 为空时立即抛 NPE）
四种安全替代方案（按推荐顺序）
不依赖 toMap 的 null 检查机制，改用更可控的方式构建 Map：
-
方案一：预过滤 null value
在流中提前排除 value 为 null 的元素：list.stream().filter(item -> item.getValue() != null).collect(Collectors.toMap(Item::getKey, Item::getValue)) -
方案二：提供默认值代替 null
用三元表达式或 Optional 提供兜底值：.collect(Collectors.toMap(Item::getKey, item -> item.getValue() != null ? item.getValue() : "N/A")) -
方案三：用 Collectors.toMap + merge function 显式容错
虽不能绕过 value 校验，但可结合computeIfAbsent等后续处理，更适合复杂逻辑 -
方案四：手写 collector（完全自定义）
使用Collector.of构建支持 null value 的收集器，例如基于ConcurrentHashMap或包装 HashMap 并跳过 value 检查（慎用，破坏契约）
Key 为 null 的情况怎么处理？
Key 为 null 会更早触发 NPE（甚至在进入 toMap 逻辑前），因为 key mapper 函数返回 null 后，Objects.requireNonNull 立即生效。解决方式类似：
- 过滤掉 key 为 null 的项：
.filter(item -> item.getKey() != null) - 映射为非 null key：
item -> item.getKey() != null ? item.getKey() : "UNKNOWN" - 避免在 key mapper 中返回 null（最佳实践：key 应具备业务唯一性与非空性）
调试与排查技巧
遇到 NPE 时快速定位问题源：
- 检查 stack trace 是否指向
Collectors.lambda$toMap$173或类似内部类 —— 基本确认是 toMap 的 value/null 校验失败 - 在 collect 前加
.peek(System.out::println)或断点观察流中每个元素的 key/value - 对 value 字段做防御性日志：
item -> { System.out.println("value=" + item.getValue()); return item.getValue(); } - 单元测试覆盖边界数据：构造含 null value/key 的对象列表，验证处理逻辑
本质上，toMap 的 null 限制是 API 明确的设计取舍。接受它、绕过它，而不是试图“修复”它。选择哪种方案取决于业务语义：丢弃异常数据？填充默认值？还是转为异常告警？明确这一点，选型就清晰了。
