Collector.toList() 不保证返回可变列表，JDK 9+ 可能返回不可变视图，调用 add/remove 会抛 UnsupportedOperationException；需可变时应显式使用 new ArrayList<>(...) 或 Collectors.toCollection(ArrayList::new)。
Collector.toList() 为什么有时会返回不可变集合？
Java 8 的 Collectors.toList() 不保证返回的 List 可修改——JDK 9+ 实现可能返回 Arrays.asList() 包装的不可变视图，调用 add() 或 remove() 会抛 UnsupportedOperationException。
- 如果需要可变列表，显式用
new ArrayList(...)包一层，或改用Collectors.toCollection(ArrayList::new) -
toList()语义是“收集为 List”，不承诺可变性；JDK 自己也只保证接口类型，不保证具体实现 - 单元测试里直接调
list.add(x)很容易在 JDK 17+ 环境突然失败
Collectors.toMap() 的 key 冲突怎么处理？
当流中多个元素映射出相同 key 时，toMap() 默认直接抛 IllegalStateException: Duplicate key，不是静默覆盖。
- 必须显式传第三个参数：合并函数，比如
(v1, v2) -> v1（保留第一个）、(v1, v2) -> v2（保留最新）或String::concat - 如果 value 是对象且需合并逻辑（如累加字段），合并函数里要自己处理 null 安全，
v1和v2都可能为 null - 别漏第四个参数指定 map 类型，否则默认是
HashMap，并发流下可能出问题；多线程场景建议用ConcurrentHashMap::new
自定义 Collector 性能比内置差很多？检查 finisher 和 combiner
手写 Collector 时，如果用 Collectors.collectingAndThen() 或嵌套 supplier/accumulator/finisher 逻辑不当，很容易触发额外拷贝或重复计算。
- finisher 函数不能做重活——比如把
ArrayList转成LinkedList再返回，这属于 O(n) 无谓开销 - 并行流下 combiner 必须幂等且无副作用；常见错误是让两个部分结果直接
addAll()，但没考虑线程安全，应确保容器本身支持并发或加锁 - 优先复用
Collectors.collectingAndThen()+ 内置 collector，比从零写更稳；真要定制，先 benchmark 对比toList()和你的版本在万级数据下的耗时
Collectors.groupingBy() 分组后 Map 的 key 顺序不稳定
groupingBy() 默认返回 HashMap，key 迭代顺序不保证；哪怕输入流有序，分组结果 Map 的 keySet() 也可能乱序。
- 要保持插入顺序，显式传第二个参数：
Collectors.groupingBy(keyFn, LinkedHashMap::new, counting()) - 要自然排序，用
TreeMap::new，但注意 key 类型必须实现Comparable，否则运行时报ClassCastException - 如果只是想按分组后对 value 做排序（比如每个 group 内 list 按时间倒序），得在 downstream 里嵌套
collectingAndThen(..., list -> list.stream().sorted(...).collect(...))，别指望 groupingBy 自己排序
