ArrayList和LinkedList允许存null但易致NPE；HashMap允一个null key和任意null value，ConcurrentHashMap禁止null key/value；TreeSet/TreeMap不接受null；Optional.of(null)立即抛异常，须用ofNullable。
ArrayList 和 LinkedList 允许存 null，但遍历时容易 NPE
它们底层是基于对象数组或节点引用实现的，没做 null 拦截，所以 add(null)、set(0, null) 都合法。问题出在后续操作：比如用 stream().map(...).collect() 时，中间某个 map 函数没判空，或者调用 Objects.requireNonNull() 前忘了检查，就会直接抛 NullPointerException。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 往
ArrayList或LinkedList放数据前，用Objects.nonNull()或显式!= null过滤，尤其从外部接口、DB 查询结果（如 MyBatis 返回的Map）取值时 - 遍历中需调用对象方法时，优先用
Optional.ofNullable(item).map(...).orElse(...)，别裸写item.toString() - 调试时留意堆栈里
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining这类线索——它往往意味着流式处理途中炸了，根源却在源头存了null
HashMap 和 ConcurrentHashMap 的 key 可为 null，但 value 也可，而 ConcurrentHashMap 直接拒绝 null key
HashMap 允许一个 null key（哈希值固定为 0，单独存在桶索引 0），value 也允许 null；ConcurrentHashMap 则从设计上禁止 null key 和 null value，否则抛 NullPointerException，连 put(null, "v") 都过不去。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 如果业务逻辑可能产生
nullkey（比如用用户 ID 字段查缓存，但该字段数据库允许为空），别硬塞进ConcurrentHashMap，改用HashMap或预处理成占位符如"MISSING_ID" -
HashMap.get(null)是合法操作，但返回值可能是null（key 不存在）或真实 value（key 就是null），无法区分——要用containsKey(null)先确认 - 用 Lombok 的
@Data生成equals/hashCode时，若字段含null，hashCode()会返回 0，可能导致HashMap中多个不同对象被哈希到同一桶，性能隐忧
TreeSet 和 TreeMap 不接受 null，哪怕只加一个也会抛 NullPointerException
它们依赖元素的自然顺序（Comparable）或比较器（Comparator），而 null.compareTo(...) 或 comparator.compare(null, x) 必然触发 NPE。注意：这个异常不是发生在构造时，而是第一次调用 add() 或 put() 含 null 的元素时。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 别指望靠 try-catch 来“兜底”——异常位置深（常在
TreeMap.put()内部的compare()调用），堆栈难读，应前置校验 - 若数据源不确定是否含
null，先用filter(Objects::nonNull)清洗，或改用HashSet/HashMap（只要不需排序） - 自定义
Comparator时，明确处理null：比如用Comparator.nullsFirst(Comparator.naturalOrder())，但注意这仅适用于你主动控制比较逻辑的场景，TreeSet构造时传入才生效
Optional 本身不是集合，但常和集合混用，误用 Optional.of(null) 立刻失败
Optional 是容器类，不是集合类，但它常出现在集合流式处理链中（如 list.stream().map(this::findUser).filter(Optional::isPresent).map(Optional::get)）。这时候最容易踩的坑是：把 null 直接喂给 Optional.of()，它会立刻抛 NullPointerException；必须用 Optional.ofNullable()。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 任何从集合中取单个元素再包装成
Optional的操作（如list.get(0)），一律用Optional.ofNullable(...) - 避免在
stream().map()里写Optional.of(item.getField())——如果getField()返回null，就炸了；改成Optional.ofNullable(item).map(Entity::getField) -
Optional和集合嵌套（如List<optional>></optional>）是反模式：增加理解成本，且flatMap(Optional::stream)才能扁平化，稍不注意就漏掉空值
最麻烦的不是哪个容器支持 null，而是同一个集合在不同 JDK 版本里行为微调（比如 JDK 17 对 ConcurrentHashMap 的 computeIfAbsent 中 null value 的处理更严格），还有框架封装带来的二次隐藏（Spring 的 @Cacheable 方法返回 null 时，某些缓存实现会静默丢弃，导致你以为没缓存，其实是被过滤了）。
