Java Stream API 运行时风险需从生命周期、数据状态、操作语义三方面预防：流未执行需检查终端操作；空/null 数据应提前过滤并安全解包Optional；toMap键冲突须指定合并策略；并行流禁用副作用；无限流须限流或资源管理。
Java Stream API 报错大多不发生在编译期，而是在运行时悄无声息地抛异常、丢数据或返回空结果。关键不是等报错再查，而是从流的生命周期、数据状态和操作语义三个角度提前识别风险点。
流没执行？检查有没有终端操作
Stream 是惰性的，只写 filter、map、sorted 这类中间操作，什么都不会发生。常见表现是：控制台没输出、变量仍是空、集合没变化。
- 确认链式调用末尾有 collect()、forEach()、count()、findFirst() 等终端操作
- 避免把流赋值给变量后忘记消费，例如：
Stream<String> s = list.stream().filter(...);—— 这行完事就结束了 - 调试时可在终端操作前加
peek(System.out::println)观察中间元素（仅限开发环境）
空数据或 null 元素导致 NPE 或 NoSuchElementException
空集合、null 元素、非法字符串格式，是 NullPointerException 和 NoSuchElementException 的主要来源，尤其在 map、findFirst、reduce 中极易触发。
- 创建流前先判空：
if (data != null && !data.isEmpty()) { data.stream()... } - 对可能含 null 的流，尽早过滤：
stream.filter(Objects::nonNull) -
findFirst()返回 Optional，绝不能直接调用.get()；改用.orElse("default")或.orElseGet(() -> computeDefault()) - 涉及类型转换（如
Integer::parseInt）时，在 map 内部用 try-catch 处理，避免中断整个流
Duplicate key 异常：toMap 时键重复
绝大多数 Duplicate key 报错来自 Collectors.toMap(keyMapper, valueMapper)。它默认要求所有 key 唯一，一旦两个元素生成相同 key，立刻抛 IllegalStateException。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- 典型场景：数据库查出的 List 直接转 Map，但 SQL 关联错误或脏数据导致 ID 重复
- 解决方法：改用三参数版本
toMap(keyMapper, valueMapper, (v1, v2) -> v1)，显式定义冲突策略（保留第一个、取最新、合并等） - 更安全的做法：先用
distinct()或按业务逻辑去重，再转 Map
并行流副作用引发不可预测行为
并行流不是性能银弹。一旦中间操作或终端操作修改共享变量、写日志、更新非线程安全集合，就会出现结果丢失、数据错乱甚至 ConcurrentModificationException。
- 禁止在
forEach中修改外部 ArrayList、HashMap - 避免在
filter或map中自增计数器、写文件等副作用操作 - 改用
collect(Collectors.toList())、reduce()等无副作用规约方式替代 - 小数据量（比如几百条以内）通常没必要用并行流，线程调度开销反而更高
无限流或资源未释放引发泄漏
Stream.generate()、Files.lines() 这类流若没限制或没关闭，会导致内存持续增长或文件句柄耗尽。
- 所有无限流必须搭配
limit()、findFirst()、anyMatch()等短路操作 -
Files.lines(path)必须用try-with-resources包裹，否则底层 BufferedReader 不释放 - 避免在流中缓存中间结果（如反复调用
map(...).collect(...)），Stream 本身是一次性消耗品
