Stream.filter()未生效主因是Predicate未返回boolean：常见错误包括执行副作用操作、返回非boolean类型、忽略null检查；正确做法是仅用其判断，副作用用peek()，空值需显式处理。
Stream.filter() 为什么没生效？Predicate 的返回值必须是 boolean
常见错误是把 filter() 当成“执行操作”，比如在里面调用 System.out.println() 或修改外部变量，却忘了它只认 boolean 返回值。只要 Predicate.test() 返回 false，当前元素就被丢弃，不进后续链式调用。
-
Predicate只能用于判断，不能做副作用操作；真要做日志或计数，得用peek() - 写错返回类型（比如返回
void或String）会导致编译失败，IDE 通常报错：Bad return type in lambda expression: void cannot be converted to boolean - 空值处理容易漏：如果集合里有
null，而你的Predicate没判空，运行时抛NullPointerException
示例：过滤非空且长度大于 3 的字符串
list.stream()
.filter(s -> s != null && s.length() > 3)
.collect(Collectors.toList());
map() 转换后类型变了，Function 的输入输出类型必须匹配
Function 是纯转换器，输入一个类型，输出另一个类型，中间不能“跳步”。很多人在 map() 里试图做条件分支或抛异常，结果发现流中断了或者类型擦除导致泛型报错。
- 返回
null是合法的，但后续如果接collect()一般没问题，接findFirst().orElseThrow()就可能 NPE - 如果想一边转换一边过滤（比如字符串转整数，但空字符串跳过），别硬塞在
map()里，先filter()再map() - Java 8 的
Function不支持 checked exception，捕获异常必须包装成RuntimeException，否则编译不过
示例：安全地把字符串列表转成整数列表（跳过无法解析的）
list.stream()
.filter(s -> s != null && !s.trim().isEmpty())
.map(s -> {
try {
return Integer.parseInt(s.trim());
} catch (NumberFormatException e) {
return null; // 或者用 Optional.empty() 配合 flatMap
}
})
.filter(Objects::nonNull)
.collect(Collectors.toList());
filter + map 顺序调换会影响性能和空指针风险
先 filter() 再 map() 是更安全、通常也更高效的做法。因为 map() 会为每个元素都执行转换逻辑，哪怕之后被 filter() 删掉——这浪费 CPU，还可能提前触发异常。
- 比如对
List<string></string>先map(s -> s.toUpperCase().substring(0, 1))再filter(s -> s.length() > 0)，空字符串会直接在substring()报错，而不是被过滤掉 - 如果
map操作开销大（如 IO、正则匹配、JSON 解析），前置filter能显著减少调用次数 - 某些场景下顺序不可逆：比如要从对象中提取字段再判断，就必须先
map出字段，再filter；这时要注意字段是否可空
用 Predicate 和 Function 组合时，别忽略 Stream 的短路特性
filter() 和 map() 本身不短路，但像 findFirst()、anyMatch() 这类终端操作会触发短路。这意味着：如果你的 Predicate 或 Function 里有副作用（如打印、计数），它们不一定被执行完——尤其在并行流里，执行顺序和次数都不保证。
- 调试时别依赖
System.out.println()在Predicate里打点，它可能只打一部分 - 不要在
Function中修改共享状态（如静态计数器），并行流下结果不可预测 - 短路不是优化银弹：
anyMatch()快，但collect()一定遍历全部；想提前退出得靠终端操作，不是靠中间操作
真正难的不是写对语法，而是想清楚“哪些逻辑必须每项都做，哪些可以跳过，哪些根本不能有副作用”。流式操作表面简洁，背后全是执行模型的隐含契约。
