Stream.findFirst() 总是返回Optional，空流返回Optional.empty()而非null，须用orElse()、ifPresent()等安全处理；sorted()后调用会失去短路优势，应避免；并行流中优先用findAny()提升性能。
Stream.findFirst() 返回 Optional，不是直接返回元素
很多人误以为 findFirst() 会抛异常或返回 null，其实它总是返回 Optional<t></t>。空流（比如过滤后没匹配项）会返回 Optional.empty()，不是 null —— 所以不能用 == null 判断，也不能直接调用 .get()，否则运行时抛 NoSuchElementException。
安全取值必须显式处理 empty 场景
最常用且推荐的方式是用 orElse()、orElseGet() 或 ifPresent()，取决于你的后续逻辑：
- 要提供默认值（如
0、""、new User()），用orElse(defaultVal)；注意：defaultVal总是会被计算，哪怕 Optional 非空 - 默认值构造开销大（比如查数据库、新建对象），改用
orElseGet(() -> expensiveCall())，只在 empty 时执行 - 只想在有值时做点事（比如打印、更新状态），用
ifPresent(System.out::println)，避免冗余的 if 判断
反例：stream.filter(...).findFirst().get() —— 生产环境等于埋雷。
链式过滤 + findFirst 容易忽略短路失效风险
findFirst() 本身是短路操作，但前提是上游没有强制触发全量求值。常见陷阱：
- 在
sorted()后调用findFirst()，会先完成整个排序（O(n log n)），再取第一个 —— 失去“找第一个满足条件”的本意 - 用
limit(1)配合findFirst()没意义，因为findFirst()本身已短路 - 如果数据源是并行流（
parallelStream()），findFirst()会保持 encounter order，但性能可能不如findAny()；真要极致性能且顺序不重要，改用findAny()
示例：想找第一个偶数，别写 list.parallelStream().sorted().filter(x -> x % 2 == 0).findFirst()，直接 list.stream().filter(x -> x % 2 == 0).findFirst() 即可。
和传统 for 循环对比：语义清晰但不可滥用
有人觉得 stream.filter(...).findFirst() 写起来比 for 循环长，还多一层包装。确实，在简单场景（比如遍历 List 找第一个匹配）下，传统循环更直观、无装箱开销、调试也方便：
for (int i = 0; i <p>但 Stream 方式优势在组合性：比如你要「按创建时间倒序 → 过滤启用状态 → 取第一个」，链式表达更贴近业务描述；而循环里混入排序逻辑就容易出错。关键看是否需要复用中间操作，还是纯一次性查找。</p> <p>Optional 的封装不是为了炫技，而是把“可能没有”这个事实强制暴露在类型系统里 —— 忽略它，就是放任空指针隐患在调用链下游爆发。</p>
