该用 std::map 而不是 std::unordered_map 的情况包括：需按 key 自然顺序遍历、依赖稳定迭代顺序、key 无合适哈希函数但支持 operator
什么时候该用 std::map 而不是 std::unordered_map
当你要按 key 的自然顺序遍历、或需要稳定迭代顺序（比如调试时依赖输出顺序）、或 key 类型没有合适的哈希函数但支持 operator 时，<code>std::map 是唯一选择。
常见错误现象：std::unordered_map 对自定义类型报错 error: no match for call to 'std::hash<mystruct>'</mystruct>，而你又懒得写哈希特化——这时候别硬扛，直接切 std::map。
-
std::map支持任意可比较类型（如std::string、std::pair<int int></int>、自定义结构体只要重载了operator） -
std::unordered_map要求 key 可哈希，且哈希值分布得相对均匀，否则性能退化成 O(n) - 如果频繁调用
begin()/end()做范围遍历（比如“查所有 age ≥ 25 的用户”），std::map天然支持 lower_bound/upper_bound；std::unordered_map得全表扫描
插入和查找性能差异到底差多少
平均情况下，std::unordered_map 是 O(1)，std::map 是 O(log n)；但“平均”二字很关键——它依赖哈希函数质量与负载因子控制。
实际踩坑点：小数据量（比如 n std::unordered_map 的哈希计算 + 桶寻址开销可能比红黑树的几次指针跳转还重；而且它默认最大负载因子是 1.0，一旦 rehash 就卡顿一下。
立即学习“C++免费学习笔记（深入）”；
- 用
reserve(n)预分配桶数，能避免多次 rehash；但std::map不需要这类预估 - 如果 key 是短字符串（如 ID “U12345”），GCC 的
std::hash<:string></:string>实现可能比红黑树的字符串比较还慢 -
std::unordered_map的内存占用通常高 2–3 倍（空桶 + 指针），对缓存不友好；std::map节省内存，局部性更好
迭代器失效规则完全不同
std::map 迭代器只在对应元素被 erase() 时失效；std::unordered_map 在 rehash（比如 insert 导致扩容）时，**所有迭代器全部失效**——这是最常被忽略的崩溃源头。
典型场景：边遍历边删除符合条件的项。用 std::map 可以安全地 it = m.erase(it)；但用 std::unordered_map 时，哪怕只是 m.erase(it++)，下一次 it 也可能已无效。
- 安全写法：
for (auto it = umap.begin(); it != umap.end(); ) { if (cond) it = umap.erase(it); else ++it; } - 更稳妥的做法是先收集待删 key，再统一 erase——但这就损失了
std::unordered_map的原地优势 - 如果代码里有
std::unordered_map::iterator被长期持有（比如作为类成员缓存），rehash 后就是悬垂指针
Key 相等判断逻辑不一致
std::map 用 operator 实现严格弱序，相等靠 <code>!(a 推导；<code>std::unordered_map 用 std::equal_to<key></key> 显式判断相等，并依赖独立的 std::hash<key></key>。
这意味着：如果你自定义类型重载了 operator== 但没同步改 std::equal_to 特化，或者哈希函数没和 operator== 保持一致（比如浮点数用 fabs(a-b) 判等，但哈希却直接用 bitcast），结果就是查不到本该存在的 key。
- 最简验证方式：打印
umap.bucket_count()和umap.size()，如果后者远小于前者，说明哈希冲突严重或判等出错 - 不要用
float或double做std::unordered_map的 key，除非你完全掌控哈希和判等逻辑 - 用
std::map时，只要operator 满足严格弱序（无自反、传递、可比），就不会有这类隐式陷阱
真正难的是权衡：想快，得担 rehash 和哈希质量的风险；要稳，就得接受 log n 和额外的比较开销。选哪个，取决于你手里那块数据的真实分布、访问模式，还有上线后敢不敢为一次哈希碰撞 debug 到凌晨三点。
