Stream核心是惰性求值、不存数据、不改原集合、只消费一次；filter等中间操作仅记录规则，需终端操作触发执行，并行流须满足无状态、无依赖前提，distinct依赖equals/hashCode，collect需分基础/性能/业务三层理解。
回答 Java Stream API 面试题，关键不是背操作方法名，而是讲清“为什么这么设计”和“哪里容易踩坑”。面试官真正想听的是你对惰性求值、流生命周期、纯函数约束这些底层逻辑的理解，以及能否结合业务场景做取舍。
紧扣三大本质特征讲清楚
一开口就点明 Stream 的三个不可绕过的核心：它不存数据、不改原集合、只消费一次。比如说到 filter，立刻补一句：“filter 只是记下规则，不触发执行；必须接 collect、findFirst 或 anyMatch 这类终端操作，整条链才真正跑起来——漏掉终端操作，代码静默失效，连异常都不会抛。”
再比如解释并行流，别只说“快”，要指出前提：“parallelStream() 适合计算密集、无状态、元素间无依赖的场景；若 lambda 里查数据库或改 static 变量，并行反而导致结果错乱或线程安全问题。”
用对比方式答高频操作题
被问到 filter/map/distinct 等操作时，避免罗列语法，改用对比呈现认知深度：
立即学习“Java免费学习笔记（深入）”；
- filter vs. anyMatch：前者返回新流，后者是终端操作且短路——判断是否存在满足条件的元素时，anyMatch 更轻量，找到第一个就停
- map vs. flatMap：map 是一对一（String → upperCase），flatMap 是一对多（List<Article> → 所有 tag 字符串），常用于“展开嵌套集合”
- distinct()：依赖元素的 equals + hashCode，对自定义对象务必重写这两个方法，否则去重失效
收集器 Collector 要分层说透
谈到 collect，不能只说 toList()，要体现层次感：
- 基础层：toSet() 自动去重且声明 UNORDERED；toMap() 键冲突必须显式给 mergeFunction，比如 (v1, v2) -> v1 表示保留旧值
- 性能层：toCollection(() -> new ArrayList(500)) 可预设容量，避免扩容拷贝；Java 10+ 的 toUnmodifiableList() 能防后续误修改
- 业务层：groupingBy(User::getDept, averagingDouble(User::getSalary)) —— 一行代码完成“按部门分组 + 算平均薪资”，比手写 Map 循环清晰得多
拼接与合并流要按数量选方案
两个流合并？直接说 Stream.concat(list1.stream(), list2.stream())，强调它返回 SIZED 流，利于并行优化；多个流？推荐 flatMap：Stream.of(s1, s2, s3).flatMap(Function.identity())，说明它内存友好、天然支持 Optional.stream() 过滤空流，但提醒“结果流不再有 SIZED 特性，某些优化可能降级”。
顺带提一个真实陷阱：concat 前若某个流已被 forEach 消费过，运行时报 IllegalStateException——正确做法是从原始集合重新获取流，而不是复用已关闭的流。
