filter用于筛选符合条件的元素并生成新流，不修改原数据；map用于逐个转换元素且数量不变；二者顺序影响性能与语义，通常先filter再map更优。
filter 用来保留符合条件的元素，不是“过滤掉”
很多人初看 filter 名字，以为它像数据库 DELETE 那样“删掉”不满足条件的项。其实它只是从原流中**筛选出匹配谓词（Predicate）的元素**，生成新流，原数据不动。
常见错误是写反判断逻辑，比如想取偶数却写了 x % 2 == 1；或对 null 元素没做防护，导致 NullPointerException。
- 务必确保
Predicate内部不抛未检查异常，否则流会中断 - 如果源是
Collection，filter不改变其内容，只影响后续操作 - 链式调用中，
filter尽量前置——减少后续map或reduce处理的数据量
Listnumbers = Arrays.asList(1, 2, 3, 4, 5); List evens = numbers.stream() .filter(x -> x != null && x % 2 == 0) // 防 null + 判偶 .collect(Collectors.toList());
map 负责逐个转换，类型可以变但数量不变
map 接收 Function，对每个元素执行一次转换，输出流的元素个数与输入流严格一致。它不筛选、不聚合、不跳过——哪怕你返回 null，那个 null 也会进结果流（除非后续有 filter(Objects::nonNull)）。
典型陷阱：把 map 当成 flatMap 用，比如想把 List 拆成所有字符，却写了 map(s -> s.chars().boxed().collect(...))，结果得到 List 而非扁平的 >
List。
立即学习“Java免费学习笔记（深入）”；
- 转换函数里避免副作用（如修改外部变量、IO），流可能并行执行
- 若转换后需判空或进一步处理，优先在
map后接filter，而不是在map里塞三元运算返回空集合 - 注意泛型擦除：从
String映射到LocalDate时，别漏了DateTimeParseException的捕获（建议提前 validate 或用Optional包装）
Listdates = Arrays.asList("2023-01-01", "2023-02-30"); List parsed = dates.stream() .map(s -> { try { return LocalDate.parse(s); } catch (DateTimeParseException e) { return null; // 后续 filter 可剔除 } }) .filter(Objects::nonNull) .collect(Collectors.toList());
filter 和 map 的顺序会影响性能和语义
先 filter 再 map 通常是更优选择，尤其当 map 操作开销大（如解析 JSON、查库、IO）时。反过来不仅浪费计算，还可能因无效输入触发异常。
但也有例外：比如你需要基于转换后的值做判断（如 “找出所有转成整数后大于 100 的字符串”），那就必须先 map 再 filter —— 此时建议把解析逻辑封装好，并用 Optional 或异常处理兜底。
- 不要为了“一行写完”强行嵌套复杂逻辑，可提取为私有方法提升可读性
- 并行流中，
filter和map都是无状态操作，可安全并行，但顺序仍由链式调用决定 - 调试时可用
peek查看中间结果，但上线前务必删掉——它仅用于调试，不保证执行时机
空流、null 元素和提前终止的注意事项
Stream 本身可以为空（如 Stream.empty()），filter 和 map 都能正常处理；但若流中包含 null 元素，而你的 map 或 filter 函数没做防御，就会炸。
另一个易忽略点：findAny、findFirst 等短路操作，在 filter 后可能提前结束，但 map 总是全量执行（除非上游已短路）。所以别指望 “filter(...).map(...).findFirst()” 会让 map 只跑一次。
- 对可能含
null的集合，初始化流前先用Collection.removeIf(Objects::isNull)，或在filter中统一拦截 -
map返回null是合法的，但后续收集到List没问题，收集到Map（如用toMap）就会抛NullPointerException - 需要“找到第一个满足条件并转换”的语义，用
filter(...).map(...).findFirst()是对的；但若转换成本高，考虑用传统 for 循环手动控制
