java stream api 面试重点在于理解适用场景与陷阱：惰性求值导致stream只能消费一次；并行流仅适用于大数据量cpu密集型任务；collectors可组合实现分组聚合；简单逻辑、需索引或调试时应优先选传统循环。
Java Stream API 是面试中高频考点，重点不在背方法名，而在理解“何时用、怎么用、为什么这么用”。真正拉开差距的，不是能不能写出 filter().map().collect()，而是能否在业务场景中合理取舍——比如该用并行流吗？中间操作能合并吗？会不会无意中触发多次遍历？
Stream 的惰性求值与常见陷阱
Stream 操作分为中间操作（如 filter、map、sorted）和终端操作（如 collect、forEach、count）。中间操作不会立即执行，只有遇到终端操作才真正触发流水线。
- 错误写法：连续调用两次
count()—— Stream 只能消费一次，第二次会抛IllegalStateException - 避免重复遍历：如果既要统计总数又要找最大值，别分别调
count()和max()，改用Collectors.teeing()或一次性收集到自定义对象 - 调试技巧：用
peek()查看中间结果（仅限开发/测试），但别在生产逻辑里依赖它做副作用操作
并行流（parallelStream）的真实适用场景
并行流不等于“更快”，它引入了分治、拆分、合并、线程调度等开销。小数据量或简单操作反而更慢。
- 适合场景：CPU 密集型、数据量大（通常 > 10,000 元素）、操作无状态且无外部依赖（比如纯数学计算、字符串转换）
- 慎用场景：涉及 I/O、加锁、修改共享变量、依赖顺序（如
findFirst()在并行下语义变化）、使用forEach（无序）而你又需要顺序保证 - 替代方案：明确需要并发处理时，优先考虑
CompletableFuture+ 普通 Stream，可控性更强
Collectors 的进阶组合与定制
很多候选人止步于 toList() 或 toMap()，但面试官常考察更贴近业务的聚合能力。
- 去重+合并：用
Collectors.toMap(key, value, (v1, v2) -> v1)处理键冲突，比先distinct()再 collect 更高效 - 分组后二次聚合：比如按部门分组，再统计每组平均薪资 —— 用
groupingBy(dept, averagingDouble(Employee::salary)) - 自定义 Collector：当内置 Collectors 不够用（如滑动窗口统计、带校验的累加），实现
Supplier/Accumulator/Combiner三要素即可，不必复杂化
Stream vs 传统循环：什么时候不该用 Stream？
Stream 是声明式抽象，不是银弹。过度使用反而降低可读性和性能。
- 简单迭代就退出：比如“找第一个满足条件的元素并 break”，用 for-loop + if-break 更直观，也避免创建 Stream 对象开销
- 需要索引或前后依赖：Stream 本身不暴露索引，强行用
AtomicInteger或IntStream.range()反而难维护 - 嵌套结构扁平化困难：比如 List
- > 转成单层 list，
flatMap可行，但三层嵌套时，递归 + for 更清晰 - 调试困难：链式调用中某步出错，堆栈信息不如传统代码定位直接；单元测试也更难打桩或断点
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
