Stream.toList() 更安全，因其返回不可变列表，避免误修改；而 collect(Collectors.toList()) 返回可变 ArrayList，需手动包装防改。
Stream.toList() 为什么比 collect(Collectors.toList()) 更安全
Java 16 引入的 Stream.toList() 返回的是不可变列表，而 collect(Collectors.toList()) 返回的仍是可变的 ArrayList（具体类型取决于收集器实现，但默认是可变的）。这意味着你不再需要手动包装成 Collections.unmodifiableList() 来防误改——只要没显式转型，就根本改不了。
常见错误现象：list.add(x) 在运行时抛出 UnsupportedOperationException，但不是因为用了 toList()，而是你把它转成了 (ArrayList) stream.toList() 或类似强制类型转换。
- 它返回的是私有不可变实现（
ImmutableCollections.ListN），不暴露构造器，也不继承ArrayList - 如果你依赖
ArrayList的特定行为（比如ensureCapacity()、随机写入性能假设），这里会静默失效 - 兼容性注意：Java 15 及更早版本无法编译通过，别在还没升级 JDK 的项目里直接切
toList() 和 toUnmodifiableList() 到底选哪个
Stream.toList() 就是 Collectors.toUnmodifiableList() 的语法糖，二者语义完全一致。Java 16+ 中它们底层共享同一套不可变集合逻辑，返回的对象也完全相同（都是同一个私有类实例）。
使用场景差异只在代码可读性和 JDK 版本适配上：
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
toList()更短，适合新项目或已确定最低 JDK 为 16+ 的环境 -
toUnmodifiableList()显式强调“不可变”，对团队中不熟悉 Java 16 新特性的成员更友好 - 如果项目需兼容 Java 15（比如部分模块还在用 Spring Boot 2.4.x），只能用后者，否则编译失败
遇到 UnsupportedOperationException 不一定是 toList() 的锅
这个异常常被误认为是 toList() “太严格”，其实绝大多数情况是你在后续代码里做了非法操作，比如：
- 把返回值强制转成
ArrayList：(ArrayList) stream.toList() - 传给某个方法后，该方法内部调用了
add()、remove()、set() - 用在需要可变 List 的框架 API 中（如某些旧版 MyBatis 动态 SQL 构造器）
典型错误示例：
List<String> list = stream.toList(); // OK<br>list.add("oops"); // 运行时报 UnsupportedOperationException这不是 bug，是设计使然。真要可变，请明确用 collect(Collectors.toCollection(ArrayList::new))。
替代方案对比：什么时候不该用 toList()
如果只是想“结束流并拿个容器”，toList() 很方便；但它不适合所有集合需求：
- 需要去重？别指望
toList()自带 dedup，得先distinct() - 要保持插入顺序但又需快速查找？
toList()查找是 O(n)，考虑toMap(x -> x, x -> x)或后续转Set - 数据量极大（百万级）且只读一次？
toList()仍会全量加载进内存，不如用forEach()流式处理 - 下游要序列化（如 JSON）？某些库对不可变集合支持不完善，可能报错或忽略字段
不可变性是优点，也是约束。它省了防御性拷贝，但也锁死了后续修改路径——这点比函数名本身更值得盯住。
