函数式接口重构需坚持明确意图、不可变、无副作用原则，核心是厘清“找什么（filter）、变什么（map/flatmap）、要什么（终端操作）”，避开副作用、空值、foreach滥用等反模式，并依数据规模合理取舍stream。
函数式接口重构不是把 for 换成 stream 就完事，而是用 明确意图 + 不可变 + 无副作用 的方式重写逻辑。重点不在“用了没”，而在“用得对不对、稳不稳、省不省”。
先理清三个核心问题：找什么？变什么？要什么？
这是所有 Stream 改造的起点。不回答清楚，就容易写出又长又难懂的链式调用。
-
找什么 → 用
filter()：比如.filter(u -> u.getAge() > 18 && "NORMAL".equals(u.getStatus())) -
变什么 → 用
map()或flatMap()：比如.map(this::toDto)或.flatMap(u -> u.getOrders().stream()) -
要什么 → 看结果形态选终端操作：
→ 列表：.collect(Collectors.toList())
→ 单个值：.findFirst()或.reduce(...)
→ 统计：.count()、.summingInt(User::getAge)
避开常见反模式，尤其注意副作用和空值
函数式写法一旦混入状态修改或空指针，比传统 for 更难排查。
- 别在
map或filter里改原对象：
错误：.map(u -> { u.setActive(true); return u; })
正确：.map(u -> new ActiveUser(u))或.map(User::toActive) - 空值必须显式处理，别依赖
Objects::nonNull了事：
优先用Optional.ofNullable(list).orElse(Collections.emptyList()).stream()，避免流中途抛 NPE -
forEach只用于日志或调试；业务中需遍历执行动作，回归 for 循环更清晰、可控
用对 Lambda 和方法引用，让代码真正变短且自解释
不是所有匿名类都该换，但以下场景替换后提升明显：
- 线程/定时任务：
new Thread(() -> doWork()).start();替代匿名Runnable - 排序：
list.sort(Comparator.comparing(User::getAge).reversed());比手写Comparator匿名类少 6 行、零出错 - 转换与构造：
list.stream().map(UserDTO::new).collect(...)或Collectors.toMap(User::getId, User::getName)
性能与取舍：小数据不用强上 Stream，大集合慎用并行流
Stream 是工具，不是银弹。盲目套用反而拖慢系统。
- 集合元素少于 200 个，for 循环通常更快，JIT 优化充分，无流创建开销
-
parallelStream()仅在 CPU 密集型、无锁、无共享状态时才稳定提效；IO 或同步操作下可能更慢，甚至引发线程安全问题 - 大数据量过滤+映射，优先考虑
mapToInt/mapToLong原始流，避免装箱开销
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
