Java集合存null时filter不报错但结果可能错误，因filter仅执行谓词逻辑，若谓词中调用null方法会抛NPE；Objects::nonNull仅过滤不处理后续，需确保下游操作安全；Optional不自动防NPE，误用get仍崩溃；ConcurrentHashMap.computeIfAbsent禁止返回null；Arrays.asList允许null但stream处理需谨慎。
Java集合里存了null，stream().filter() 为啥不报错但结果不对
因为 filter() 只做逻辑判断，不会主动拒绝 null；如果谓词里写了 obj.toString() 或 obj.equals(...) 这类方法调用，运行时就会抛 NullPointerException。但更隐蔽的问题是：你写了 Objects::nonNull 却忘了它只判非空，不处理后续操作——比如 map() 里又调了 null 的方法。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 在
filter(Objects::nonNull)后，所有下游操作（map、reduce、forEach）都默认安全，但别假设上游已“清洗干净”——检查原始集合是否真被修改过 - 若集合本身允许
null（如HashMap的 value、ArrayList），别依赖filter隐藏问题，而应从源头控制：构造时用Collections.unmodifiableList()包一层，或改用Optional包装元素 - 调试时加一句
System.out.println(list.stream().map(String::valueOf).collect(Collectors.toList()))，能快速暴露哪些位置是null字符串化成"null"
用 Optional 包装集合元素，真能防住 NPE 吗
不能自动防住。把 List<string></string> 改成 List<optional>></optional>，只是把 null 转成了 Optional.empty()，但如果你写 opt.get() 而不是 opt.orElse("default")，照样崩。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 仅当业务语义上“缺失值有意义”时才用
Optional，比如配置项未设置、API 返回字段可选；普通集合遍历场景下，它反而增加冗余对象和 GC 压力 - 不要把
Optional当null替代品塞进集合——JDK 自己都不鼓励：Optional不实现Serializable，不能作为字段或 JSON 序列化字段使用 - 真正安全的写法是组合：先
filter(Optional::isPresent)，再map(Optional::get)，但不如直接filter(Objects::nonNull)直观
ConcurrentHashMap 的 computeIfAbsent 遇到 null 怎么办
这个方法明确禁止 null 作为计算结果返回：如果 lambda 返回 null，会直接抛 NullPointerException，连插入都不做。这不是 bug，是设计契约——它要求“要么生成有效值，要么不生成”。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 别在 lambda 里写可能返回
null的逻辑，比如调用一个可能返回null的 DAO 方法；应提前兜底：computeIfAbsent(key, k -> service.find(k).orElse(new DefaultObj())) - 如果业务确实需要表达“查无此值”，改用
computeIfPresent+ 单独维护一个Set记录“已确认不存在的 key” - 注意
computeIfAbsent在 key 已存在且 value 为null时不会触发计算——它只看 key 是否存在，不看 value 是否为null
为什么 Arrays.asList(null, "a", null) 看似正常，但转 stream 后 filter 失效
因为 Arrays.asList() 返回的是固定大小的内部列表，它允许 null 元素；但一旦你对它调用 stream()，流里的每个元素就是原始引用，filter 对 null 的判断完全取决于你给的谓词——写错谓词就漏掉或误删。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 避免用
Arrays.asList()构造含null的集合，改用new ArrayList(Arrays.asList(...))后手动清理，或用Stream.of(...).filter(Objects::nonNull).collect(Collectors.toList()) - 测试时别只测非空分支，加一条
assertThat(list).containsNull()（用 AssertJ）或手动遍历验证null位置 - IDEA 默认不警告
Arrays.asList(null)，但开启 “Constant conditions & exceptions” 检查后，会对if (obj == null)这类显式比较标灰——说明编译器其实知道你在碰null
最常被忽略的一点：集合本身的泛型擦除不会阻止 null 存入，但现代 Lombok 的 @NonNull 或 IntelliJ 的 @NotNull 注解，只能约束参数/返回值，对集合元素无效。想真正守住边界，得靠构造时校验、不可变封装、或自定义集合子类重写 add 方法。
