std::map合并时insert复制元素而merge移动元素，c++17起支持；merge不覆盖已存在键，要求类型完全一致；unordered_map合并需reserve或rehash避免性能退化。
std::map 合并时 insert 和 merge 的区别
直接用 insert 会复制所有元素，而 merge（C++17 起）是移动语义，原 map 中匹配的键值对会被移走，不触发拷贝构造——这对大对象（比如 std::String 或自定义类型）性能差异明显。
常见错误：在 C++14 或更低版本里调用 merge，编译报错 no member named 'merge'；或者误以为 merge 会覆盖目标容器中已存在的键，其实它只会“偷”源容器里**目标中没有的键**，已有键直接跳过。
-
insert安全兼容所有 C++ 标准，但对每个元素调用一次value_type构造，可能触发深拷贝 -
merge要求两个 map 的 key_type 和 value_type 完全一致（包括 const/volatile 限定），否则编译失败 - 如果想“以右覆盖左”，
merge不行，得先遍历右 map 手动赋值或用insert_or_assign（C++17）
合并时 key 冲突怎么处理（覆盖 or 忽略）
默认行为都是忽略冲突：无论是 insert 还是 merge，遇到目标 map 已存在相同 key 的元素，都不会覆盖。真要覆盖，得手动干预。
典型场景：配置合并、缓存更新、多来源数据聚合。这时候不能依赖容器原生接口“自动覆盖”。
立即学习“C++免费学习笔记（深入）”；
- 用
insert_or_assign替代insert：对每个std::pair<const k v></const>单独处理，已存在则替换 value - 用
try_emplace可避免重复构造 value（适合 value 构造开销大且多数 key 不存在的情况） - 别写
dst[key] = src[key]—— 对不存在的 key 会默认构造 value，再赋值，白白多一次构造
std::unordered_map 合并要注意哈希和桶的问题
std::unordered_map 合并后性能可能骤降，不是因为逻辑错，而是桶数量没及时调整。直接 insert 大量元素后，负载因子飙升，查找退化成 O(n)。
错误现象：合并完看起来没问题，但后续 find 慢得异常，size() 正常但 bucket_count() 还是老样子。
- 合并前调用
reserve预估总大小（比如dst.reserve(dst.size() + src.size())），能显著减少 rehash 次数 -
merge对unordered_map同样可用（C++17），但它不会自动 rehash；合并后建议手动rehash(0)触发重散列 - 两个 map 的
hash_function()和key_eq()必须可比较相等，否则merge编译失败（尤其自定义哈希时容易漏掉operator==）
跨 map 类型合并（比如 map 到 unordered_map）
没有隐式转换，也不能直接 merge，必须显式遍历 + 插入。这时重点不是“能不能”，而是“要不要保留顺序”和“有没有重复 key 处理逻辑”。
比如把有序的 std::map<int std::string></int> 合进无序的 std::unordered_map，你其实放弃了 key 的遍历顺序保证，但换来了平均 O(1) 查找。
- 用范围 for 循环最稳妥：
for (const auto& p : src) dst.insert(p)，清晰且兼容所有标准 - 如果 src 是临时对象，考虑用
std::make_move_iterator包裹 begin/end，避免 value 拷贝（前提是 value 支持移动） - 别用
dst.insert(src.begin(), src.end())对 unordered_map —— 这个重载在 C++11/14 里不接受迭代器对，编译不过；C++17 起才支持，但依然不保证效率
真正麻烦的不是语法，是搞清你到底要“物理合并”还是“逻辑合并”：前者关心内存和速度，后者关心 key 冲突策略和 value 生命周期。很多人卡在 merge 报错，其实只是忘了检查 C++ 标准版本或 hash 函数一致性。