Stream API是声明式数据处理抽象层，具惰性求值、不可重用、无状态、并行需谨慎等特性；误用常见于重复遍历、有副作用操作、盲目并行及忽视资源管理。
Stream API不是“高级for循环”，而是声明式数据处理的抽象层——理解这一点，才能避开80%的误用陷阱。
Stream的惰性求值机制：操作不执行，只有终端操作才触发
map、filter、sorted等中间操作只是“记下要做的事”，不会立即处理数据。真正执行是在collect、count、findFirst等终端操作调用时，整个流水线才一次性遍历源集合。
- 错误写法：连续调用两次forEach，会遍历两次源集合（Stream不可重用）
- 正确做法：把多个逻辑合并进一次终端操作，或转为List/Array后复用
- 调试技巧：用peek()观察中间结果（仅用于调试，不可用于业务逻辑）
不可变性与无状态：中间操作必须是无副作用的纯函数
Stream设计默认假定每个元素的处理彼此独立。若在lambda中修改外部变量、写日志、更新数据库，不仅违反函数式原则，还可能在并行流中引发竞态问题。
- 避免在map/filter里做System.out.println或++counter
- 收集结果统一用collect(Collectors.toList())、toMap()等标准收集器
- 如需累积状态（如计数、拼接），优先用reduce或专门的收集器（如Collectors.summingInt）
并行流不是性能银弹：何时用parallelStream？
parallelStream底层用ForkJoinPool，适合CPU密集、数据量大（通常≥10000）、操作无状态且无I/O的场景。小数据集或含同步操作时，并行反而更慢。
- 典型适用：对十万级数字列表做数学变换+统计
- 典型不适用：读文件、调HTTP接口、加锁操作、ArrayList子列表切分
- 验证方式：用System.nanoTime()对比串行/并行耗时，别凭直觉
常见陷阱与替代方案
Stream写得“炫酷”不等于写得好。有些需求用传统循环更清晰、更可控。
- 需要break/continue逻辑？→ 改用for循环，Stream没有原生中断支持
- 要处理索引？→ 不要强行用IntStream.range，考虑加个AtomicInteger或改用传统遍历
- 源是IO流或数据库游标？→ Stream不自动关闭资源，优先用try-with-resources封装，勿直接stream化InputStream
- 频繁增删集合？→ Stream基于不可变语义，增删请用常规List操作
