Collectors.toMap的合并函数是业务逻辑的显式表达，需用纯函数按语义选优、构造不可变对象，并满足结合律；一对多场景应优先用groupingBy而非强行toMap。
Collectors.toMap 的高级合并函数不是“兜底补丁”，而是业务逻辑的显式表达。关键在于把 BinaryOperator
按业务字段选优，而非简单覆盖
当 value 是对象（如 User、Order、Product），不能靠引用或默认 equals 判断。必须根据上下文语义做取舍：
- 保留时间更新的记录：(prev, curr) → prev.getUpdatedAt().isAfter(curr.getUpdatedAt()) ? prev : curr
- 取分数更高者：(a, b) → a.getScore() >= b.getScore() ? a : b
- 优先保留非空备注：(a, b) → StringUtils.isNotBlank(a.getRemark()) ? a : b
构造不可变结果，避免副作用
合并函数必须是纯函数：不修改入参、不访问外部变量、不抛异常、不依赖执行顺序。推荐用 builder 模式构造新实例：
- 拼接字段并新建对象：(u1, u2) → u1.toBuilder().remark(u1.getRemark() + " | " + u2.getRemark()).build()
- 累加数值并封装：(o, n) → new Stat(o.getCount() + n.getCount(), Math.max(o.getMax(), n.getMax()))
- 错：(u1, u2) → { u1.setRemark(...); return u1; } —— 修改原对象，多线程下行为不可控
支持并行流的合并逻辑要满足结合律
若使用 parallelStream()，mergeFunction 可能被任意分组调用多次。确保 (a ○ b) ○ c == a ○ (b ○ c)：
- ✅ 安全：Integer::sum、String::concat、Math::max、BigDecimal::add
- ❌ 危险：s1.substring(0, 1) + s2、new ArrayList(list1).addAll(list2)
- ⚠️ 注意：List 合并若坚持用 toMap，应返回新 List：(l1, l2) → Stream.concat(l1.stream(), l2.stream()).collect(Collectors.toList())
当“一对多”成为常态，就该换思路
如果反复在 mergeFunction 里写 list1.addAll(list2)，说明你其实需要的是分组聚合，不是键值映射：
- 用 groupingBy 更自然：Collectors.groupingBy(Person::getName, Collectors.mapping(Person::getAge, Collectors.toList()))
- toMap 强行模拟集合会增加复杂度、降低可读性，且难以保证线程安全
- 真正需要 toMap 的场景，是最终每个 key 必须对应唯一确定的 value（哪怕这个 value 是聚合后的对象）
