filter用于筛选符合条件的元素并生成新流,不修改原数据;map用于逐个转换元素且数量不变;二者顺序影响性能与语义,通常先filter再map更优。
很多人初看 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 接收 Function,对每个元素执行一次转换,输出流的元素个数与输入流严格一致。它不筛选、不聚合、不跳过——哪怕你返回 null,那个 null 也会进结果流(除非后续有 filter(Objects::nonNull))。
典型陷阱:把 map 当成 flatMap 用,比如想把 List 拆成所有字符,却写了 map(s -> s.chars().boxed().collect(...)),结果得到 List 而非扁平的 >
List。
map 后接 filter,而不是在 map 里塞三元运算返回空集合String 映射到 LocalDate 时,别漏了 DateTimeParseException 的捕获(建议提前 validate 或用 Op
tional 包装)Listdates = Arrays.asList("2025-01-01", "2025-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 通常是更优选择,尤其当 map 操作开销大(如解析 JSON、查库、IO)时。反过来不仅浪费计算,还可能因无效输入触发异常。
但也有例外:比如你需要基于转换后的值做判断(如 “找出所有转成整数后大于 100 的字符串”),那就必须先 map 再 filter —— 此时建议把解析逻辑封装好,并用 Optional 或异常处理兜底。
filter 和 map 都是无状态操作,可安全并行,但顺序仍由链式调用决定peek 查看中间结果,但上线前务必删掉——它仅用于调试,不保证执行时机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 循环手动控制