Collections.replaceAll对List不起作用的根本原因是它仅适用于支持set()操作的可变列表；若传入Arrays.asList()返回的列表或Collections.unmodifiableList()封装的列表，会静默失败。
为什么 Collections.replaceAll 对 List 不起作用？
直接调用 Collections.replaceAll 修改 ArrayList 或 LinkedList 时，常发现值没变——根本原因是该方法只对 可变列表（mutable list） 生效，且要求底层支持 set() 操作；而如果你传入的是 Arrays.asList() 返回的列表、或被 Collections.unmodifiableList() 封装过的列表，它会静默失败（不报错，但无效果）。
常见错误现象：Collections.replaceAll(list, 500, 200) 执行后，list 内容原封不动。
- 确认列表是否可修改：打印
list.getClass().getName()，若为java.util.Arrays$ArrayList或带Unmodifiable字样，就不能用 - 检查是否用了
list = Collections.unmodifiableList(list)后又试图替换 -
Collections.replaceAll是就地修改，不返回新列表，别误以为要赋值
正确用法：确保列表可修改 + 明确类型边界
Collections.replaceAll 本身没问题，但必须配合真正的可变列表。最稳妥的做法是显式创建 ArrayList：
List<integer> codes = new ArrayList(Arrays.asList(500, 404, 500, 200, 500)); Collections.replaceAll(codes, 500, 200); // ✅ 成功将所有 500 → 200 </integer>
注意参数顺序：Collections.replaceAll(list, oldVal, newVal)，其中 oldVal 和 newVal 类型必须与列表元素类型一致（泛型擦除后靠 equals() 判断，所以自定义对象需重写 equals）。
- 若列表元素是字符串状态码（如
"ERROR"），确保传入的oldVal是相同引用或equals为true的对象 - 对
null值替换也有效：Collections.replaceAll(list, null, "OK")，但前提是列表本身允许null - 性能上无额外开销，就是一次遍历 +
set()调用，比手写 for 循环略简洁，但不如stream().map()函数式表达清晰
更推荐的替代方案：用 replaceAll() 实例方法
JDK 8+ 的 ArrayList 和多数标准实现都提供了实例方法 replaceAll(UnaryOperator)，语义更明确、类型安全更好，且无需担心不可变包装问题：
List<integer> codes = new ArrayList(Arrays.asList(500, 404, 500)); codes.replaceAll(code -> code == 500 ? 200 : code); </integer>
这个方法天然要求列表可修改，否则抛 UnsupportedOperationException，错误暴露得早，比 Collections.replaceAll 更易调试。
- 支持复杂逻辑：比如把所有 4xx 替换为 200，
code -> (code >= 400 && code - 避免
Integer缓存陷阱：用==比较小整数（-128~127）虽快，但超出范围会出错，建议统一用.equals()或Objects.equals() - 如果原始列表来自第三方 API 且不能确定可变性，优先用此方法并捕获异常，比静默失败更可靠
批量修正 HTTP 状态码时的典型坑
实际业务中，状态码常混在 Map 或嵌套对象里，直接对 List 调用 replaceAll 容易漏掉深层字段。例如：
List<map object>> responses = ...; // ❌ 下面这行只改了外层 list 的元素（即整个 map），不是 map 里的 status 字段 Collections.replaceAll(responses, 500, 200); </map>
真正需要的是遍历 + 提取 + 替换。这时候 Collections.replaceAll 完全不适用，必须用显式循环或 stream()：
responses.forEach(r -> {
Object status = r.get("status");
if (Objects.equals(status, 500)) {
r.put("status", 200);
}
});
- 别假设状态码一定是
Integer：可能是String（"500"）、Long，甚至HttpStatus枚举，先做类型判断再替换 - 并发场景下，若列表被多线程读写，
Collections.replaceAll非线程安全，需加锁或改用线程安全集合 - 日志里打点验证替换结果时，别只看 size，要抽样检查具体值，尤其注意
0、null、负数等边界状态码是否被误伤
真正难的从来不是怎么调一个方法，而是搞清数据在哪、能不能动、动了之后谁还依赖它——状态码这种跨层透传的值，改之前最好 grep 一下整个项目里它的使用路径。
