Stream是惰性、只读的，不修改原集合；重复使用会抛IllegalStateException；collect需选对收集器；并行流慎用；空值和null须显式处理。
Stream不会修改原始集合，但要注意中间操作的惰性
Java的Stream是只读视图，调用filter、map等方法不会改变原List或Set。但新手常误以为链式调用后原集合已“被处理”，结果后续还拿它做业务逻辑，导致数据不一致。
- 所有中间操作（如
filter、sorted、distinct）都是惰性的，只有遇到终端操作（如collect、forEach、count）才会真正执行 - 重复调用同一
Stream会抛IllegalStateException：“stream has already been operated upon or closed” - 如果需要多次遍历，得重新生成
Stream：用list.stream()而不是缓存一个Stream对象
collect(Collectors.toList())不是唯一选择，选错会导致性能问题
用collect收集结果时，Collectors.toList()返回的是不可变且无特定实现保障的List，JDK内部可能用ArrayList，也可能用其他实现——它不保证可扩容、不支持add，也不保留插入顺序（虽然当前版本实际保留）。
- 需要可变列表？直接用
new ArrayList(...)或Collectors.toCollection(ArrayList::new) - 要保持插入顺序且去重？用
Collectors.toCollection(LinkedHashSet::new)，比先distinct()再toList()更高效 - 聚合为
Map时，注意Collectors.toMap在key重复时默认抛IllegalStateException，需显式传入合并函数，例如：(v1, v2) -> v1
并行流不是万能加速器，慎用在有状态或IO操作中
把stream()换成parallelStream()并不总能提速，尤其当元素少、操作轻量（如toString()）、或含同步/IO（如System.out.println）时，反而因线程调度开销变慢，甚至引发竞态。
- 适合场景：CPU密集型、无状态、元素量大（通常 > 10000）、各元素处理相互独立
- 避免在
forEach里写System.out::println——输出会乱序，且锁竞争严重；改用peek+ 日志框架，或先collect再统一输出 - 不要在
parallelStream中修改共享变量（如int count = 0;然后forEach(x -> count++)），应改用AtomicInteger或reduce
空集合和null值处理不当会直接抛NPE
Stream.of(null)合法，但null进入map或filter后若未判空，终端操作时极易触发NullPointerException；而空集合调用stream()没问题，但误用findFirst().get()会炸。
立即学习“Java免费学习笔记（深入）”；
- 安全取首元素：用
findFirst().orElse(null)或findFirst().orElseThrow(() -> new RuntimeException("empty")) - 过滤前先剔除
null：stream().filter(Objects::nonNull) - 映射可能为
null的字段：用map(x -> x.getFoo()).filter(Objects::nonNull)，别写map(x -> x.getFoo()).filter(f -> f != null)——后者在x为null时就NPE了
List<String> names = Arrays.asList("Alice", null, "Bob", "");
List<String> safeNames = names.stream()
.filter(Objects::nonNull) // 先滤掉null元素
.filter(s -> !s.trim().isEmpty()) // 再滤掉空字符串
.map(String::toUpperCase) // 安全映射
.collect(Collectors.toList());
Stream API的简洁背后藏着不少隐式契约：惰性求值、不可变性、线程模型约束、空值边界。写完一行stream()链，最好反问一句——这个流谁负责关闭？中间有没有隐式依赖？终端操作会不会被意外跳过？ 
