filter()不会修改原集合且需终端操作才执行，谓词须为纯函数、线程安全，避免在其中做io或修改状态；空值需预检，linkedlist慎用stream。
filter() 方法的正确用法和常见误判
Java Stream 的 filter() 不会修改原集合，它返回的是一个新流；如果漏掉 collect() 或终端操作，整个链式调用不会执行，也不会报错——这是最常被忽略的“静默失效”。
实际使用中必须确保流有终端操作，否则过滤逻辑形同虚设。
- 错误写法：
list.stream().filter(x -> x > 10);（没终端操作，什么都不会发生） - 正确写法：
list.stream().filter(x -> x > 10).collect(Collectors.toList()); - 若只需判断是否存在满足条件的元素，用
anyMatch()比filter().findAny().isPresent()更高效
避免在 filter() 中做重操作或副作用
filter() 的谓词函数应是纯函数：无状态、无 IO、不修改外部变量。一旦在里面调数据库、发 HTTP 请求或改全局变量，不仅性能崩盘，还可能因并行流（parallelStream()）导致不可预测行为。
- ❌ 危险示例：
filter(x -> callExternalApi(x))（每次过滤都触发网络请求） - ✅ 安全做法：提前把依赖数据查好，缓存为
Set或Map，再用contains()判断 - 并行流下
filter()可能被多线程并发调用，务必确认谓词线程安全
与传统 for 循环对比：什么时候不该用 filter()
不是所有过滤场景都适合 Stream。当需要提前退出、复用中间结果、或处理超大集合（如上百万条且内存敏感）时，传统循环反而更可控。
- 需要“找到第一个匹配即停止”？
stream.filter(...).findFirst()是 OK 的，底层做了短路优化 - 但若要“过滤后统计 + 取前 N 条 + 再按某字段分组”，链式调用易读性下降，不如分步用
ArrayList缓存中间结果 - 对
ArrayList过滤性能接近循环；但对LinkedList，Stream 会因随机访问慢而显著拖累性能
空值和异常处理的实际策略
filter() 内部抛出异常会导致整个流中断，并抛出 RuntimeException（如 NullPointerException）。它不接受受检异常，也不能直接 try-catch。
- 预防空指针：用
Objects.nonNull()或Optional.ofNullable()包装判断逻辑 - 转换受检异常：把 IO 操作移到 filter 外，或封装成返回
Optional的工具方法，再用flatMap()展开 - 示例安全写法：
stream.filter(Objects::nonNull).filter(x -> x.getName() != null && x.getName().length() > 0)
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
