replaceAll 直接修改原 List，不创建副本也不返回新集合；它要求 List 支持随机访问且可修改，对 unmodifiableList 会抛 UnsupportedOperationException，多线程下不安全，lambda 类型需严格匹配，不能增删元素或提前退出。
replaceAll 方法到底改的是原 List 还是副本？
replaceAll 直接修改原 List，不返回新集合，也不创建副本。它和 stream().map().collect() 本质不同——后者生成新对象，前者是就地更新（in-place）。如果你误以为它像函数式操作一样“无副作用”，后续还拿着旧引用做判断，大概率出错。
- 只对支持随机访问且可修改的
List实现有效（ArrayList行，LinkedList也行但性能差；Arrays.asList()返回的列表行，但底层数组被改了；unmodifiableList会直接抛UnsupportedOperationException - 如果
List是由Collections.unmodifiableList()包装的，调用replaceAll会在运行时失败，错误信息是：java.lang.UnsupportedOperationException - 多线程环境下不安全，没有内置同步，别在并发修改场景里直接用
lambda 参数类型必须和 List 元素类型严格匹配
编译器不会自动拆箱或隐式转型。比如 List<integer></integer> 传入 (int x) -> x * 2 会报错：参数类型不兼容。Java 推导的是泛型类型，不是原始类型。
- 正确写法是：
list.replaceAll(x -> x * 2)（x是Integer，乘法触发自动拆箱） - 如果写成
list.replaceAll((String x) -> x.toUpperCase())，而 list 实际是List<integer></integer>，编译直接失败 - 对
Optional或自定义对象，注意 lambda 内部是否可能为null——replaceAll不跳过null元素，null会被原样传入 lambda，空指针风险得自己兜底
和 for 循环比，replaceAll 真的更简洁安全吗？
语法上确实少几行，但掩盖了两个关键约束：不能增删元素、不能提前退出。一旦你需要“遇到某个值就停”或者“满足条件就删一个”，它就不适用了。
- 无法 break 或 continue：lambda 是纯函数式语义，没控制流；想中断必须抛异常（不推荐）或改用传统循环
- 不能改变 List 长度：内部实现是按索引遍历并 set，所以 add/remove 操作会引发
ConcurrentModificationException或逻辑错乱 - 性能上，对
ArrayList是 O(n)，和普通 for 循环持平；但对LinkedList，每次set(i, ...)是 O(n) 复杂度，整体变成 O(n²)，实际中要避开
常见误用：把 replaceAll 当 filter 或 map 使用
replaceAll 的设计目标只有一个：替换每个元素为另一个同类型值。它不做筛选、不改变结构、不累积状态。拿它来“过滤 null”或“转成字符串列表”，逻辑上就拧了。
立即学习“Java免费学习笔记（深入）”；
- 想过滤？用
removeIf(x -> x == null)，或stream().filter(...).collect(...) - 想类型转换？比如
List<integer></integer>→List<string></string>，必须用stream().map(String::valueOf).collect(Collectors.toList())；replaceAll要求前后类型一致（或兼容子类），不能跨类型赋值 - 想根据上下文更新（比如“前一个元素是偶数才翻倍”）？不行，lambda 拿不到索引或邻居，得手写带索引的 for 循环
最容易被忽略的一点：它依赖 List.set(int, E) 的行为。有些 List 实现（比如某些 ORM 返回的懒加载代理列表）重写了 set 却没做好事务或脏检查，这时 replaceAll 可能静默失败或触发意外查询。真要用，先确认底层 List 的 set 是可靠且高效的。
