putAll 直接覆盖重复键，不处理冲突；merge 用 BiFunction 合并重复键值；Stream.toMap 需显式指定冲突函数，否则抛异常。
putAll 会直接覆盖重复键，别指望它自动处理冲突
putAll 的行为非常简单：遍历源 Map，对每个 entry 调用目标 Map.put(key, value)。这意味着只要键相同，后 put 的值无条件覆盖先存在的值，不回调、不提示、不合并。
常见错误现象是：合并后发现某些键“丢了”旧值，或者业务逻辑要求累加数值（比如统计次数），结果被替换成单次值。
- 适用场景仅限于“以右为尊”的覆盖合并，比如配置 fallback、测试 mock 数据覆盖
- 如果源
Map是ConcurrentHashMap，putAll仍不保证原子性，多个线程并发调用可能产生中间态 - 性能上它最轻量，但代价是零灵活性 —— 冲突策略完全不在它的职责范围内
merge 方法才是处理键冲突的正解
Map.merge 是 Java 8 引入的原生冲突处理机制，它接受一个 BiFunction 来决定重复键时如何合成新值。
典型用法是：targetMap.merge(key, value, (oldVal, newVal) -> oldVal + newVal)，适用于计数累加；或用 Objects::nonNull 选非空值等。
- 必须确保传入的
BiFunction是无副作用的纯函数，否则在并发ConcurrentHashMap中可能被多次调用 - 注意
oldVal可能为null（比如目标 Map 原本没这个键，但 merge 过程中被其他线程删了），要判空 - 对
HashMap，merge是线程不安全的；对ConcurrentHashMap，它是线程安全且原子的
示例：
map1.merge("count", 5, Integer::sum); // 若已存在 "count"=3，则变为 8
Stream.collectingAndThen + toMap 容易踩空指针和重复键异常
用 Stream 合并两个 Map 时，常见写法是 Stream.concat(m1.entrySet().stream(), m2.entrySet().stream()) 然后 collect(toMap(...))。但默认的 toMap 在遇到重复键时直接抛 IllegalStateException: Duplicate key。
必须显式提供第三个参数（冲突解决函数），否则代码运行时崩。
- 错误写法：
toMap(Entry::getKey, Entry::getValue)→ 必崩 - 正确写法：
toMap(Entry::getKey, Entry::getValue, (v1, v2) -> v1 + v2) - 如果任一 value 可能为
null，冲突函数里要处理，否则v1 + v2可能触发 NPE - 性能比
merge略低：需构造 Stream、concat、遍历两次（一次收集，一次 reduce）
复杂点其实在“谁的逻辑优先”和“是否可逆”
合并不是技术问题，是语义问题。你得先明确：重复键时，是保留左 Map 的值？右 Map 的值？还是做运算？这个决策决定了该用 putAll、merge 还是自定义 BiFunction。
更隐蔽的是可逆性：比如用 Integer::sum 合并后，原始两个值无法还原；而 putAll 至少知道“最后写入者”。如果业务需要审计或回滚，就得额外存元数据。
别跳过这步判断 —— 先想清楚“冲突意味着什么”，再选 API。不然修 bug 时翻半天才发现是语义理解反了。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
