ArrayList和LinkedList允许null，但遍历时调用item.toString()等方法会抛NPE；HashMap/HashSet有限支持null，ConcurrentHashMap禁止null；TreeSet/TreeMap默认不支持null，需自定义Comparator；Optional不应作为集合元素。
ArrayList 和 LinkedList 允许 null，但要注意遍历时的陷阱
Java 的 ArrayList 和 LinkedList 明确允许插入 null 元素，这是由其底层实现决定的——它们本质是对象引用数组或节点链表，不强制非空校验。
但问题常出现在后续操作中：
-
list.indexOf(null)能正确返回第一个null的索引；但list.contains(null)也依赖equals()，而null.equals(x)会抛NullPointerException—— 实际上contains()内部做了== null判定，所以安全；真正危险的是你自己写的循环里直接调用item.toString()或item.hashCode() - 使用 Stream 处理时：
list.stream().map(String::length).collect(...)遇到null会立即抛NullPointerException，需提前过滤：.filter(Objects::nonNull) - 序列化（如 JSON）时，
null可能被忽略或转成null字符串，和业务预期不符
ArrayList<String> list = new ArrayList<>();
list.add("a");
list.add(null);
list.add("b");
System.out.println(list.indexOf(null)); // 输出 1
System.out.println(list.contains(null)); // 输出 true
list.forEach(s -> System.out.println(s.length())); // 运行时报 NPE！
HashMap 和 HashSet 对 null 的支持是“有限宽容”
HashMap 允许一个 null 键和任意数量的 null 值；HashSet（基于 HashMap）只允许一个 null 元素，因为它是用 null 作为键存入底层 HashMap 的。
关键点在于：null 键的哈希计算被硬编码为 0，且在 get() 和 containsKey() 中有单独分支处理，不走常规 hashCode() 流程。但这不意味着可以随意混用：
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
ConcurrentHashMap完全禁止null键和null值，否则构造或 put 时直接抛NullPointerException - 若自定义类作 key 且可能为
null，不要在hashCode()或equals()中无防护地解引用字段，否则即使没存null，逻辑也可能崩 - 用
computeIfAbsent(key, mappingFunction)时，若key是null且mappingFunction返回null，结果是 map 中不存该键值对（JDK 8+ 行为），容易误判“未初始化”
TreeSet 和 TreeMap 根本不接受 null，除非显式传 Comparator
TreeSet 和 TreeMap 底层依赖元素间的可比较性，初始化时若未传 Comparator，则要求元素实现 Comparable 并调用 compareTo()。而 null.compareTo(x) 必抛 NullPointerException，所以默认构造下插入 null 会立即失败。
但有一个例外路径：
- 用带
Comparator的构造器，且该Comparator显式处理null（例如Comparator.nullsFirst(Comparator.naturalOrder())），那么null就能合法存在 - 注意：即使
TreeSet接受了null，它也只能有一个 —— 因为Comparator对null的比较结果必须满足一致性（即compare(null, null) == 0），否则集合行为未定义 - 这种写法易造成团队理解偏差，建议文档明确标注，避免后续开发者误以为“所有 Set 都能存 null”
Optional 不是集合，但常被误用来替代 null 元素
有人试图用 List<optional>></optional> 来“安全地”表示可能为空的元素，这反而增加复杂度：
- 遍历时要嵌套
optional.isPresent()+optional.get()，代码膨胀且易漏判 -
Optional设计初衷是作为**方法返回值**的容器，不是数据结构成员；把它塞进集合，等于把控制流语义混进数据容器 - 序列化库（如 Jackson）对
Optional的支持不一致，有的默认忽略，有的报错，有的转成null或包装对象 - 真要表达“可能存在”，更自然的方式是用
Collection<string></string>+ 约定空集合表示“无”，或用Optional<collection>></collection>表示“整个集合可能不存在”
集合是否支持 null 不是布尔选择题，而是每种实现各自画出的边界线。最易被忽略的不是“能不能放”，而是“放进去之后，谁会在哪一步悄悄炸掉”。比如 Arrays.asList(null) 返回的 List 在调用 removeIf 时会因内部 ArrayList 的 fast-fail 机制暴露空指针，而原生 ArrayList 不会——这种差异只有踩过才知道。
