该用 std::map 而不是 std::unordered_map 的情况包括：需按 key 自然顺序遍历、依赖稳定迭代顺序、key 无合适哈希函数但支持 operator<、需 lower_bound/upper_bound 范围查询、小数据量（n<50）、注重内存与缓存友好性、需安全边遍历边删除、长期持有迭代器、或使用浮点数作 key 等场景。
什么时候该用 std::map 而不是 std::unordered_map
当你要按 key 的自然顺序遍历、或需要稳定迭代顺序（比如调试时依赖输出顺序）、或 key 类型没有合适的哈希函数但支持 operator< 时，std::map 是唯一选择。
常见错误现象：std::unordered_map 对自定义类型报错 error: no match for call to 'std::hash<MyStruct>'，而你又懒得写哈希特化——这时候别硬扛，直接切 std::map。
-
std::map支持任意可比较类型（如std::string、std::pair<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 < 50）时，std::unordered_map 的哈希计算 + 桶寻址开销可能比红黑树的几次指针跳转还重；而且它默认最大负载因子是 1.0，一旦 rehash 就卡顿一下。
立即学习“C++免费学习笔记（深入）”；
- 用
reserve(n)预分配桶数，能避免多次 rehash；但std::map不需要这类预估 - 如果 key 是短字符串（如 ID “U12345”），GCC 的
std::hash<std::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< 实现严格弱序，相等靠 !(a < b) && !(b < a) 推导；std::unordered_map 用 std::equal_to<Key> 显式判断相等，并依赖独立的 std::hash<Key>。
这意味着：如果你自定义类型重载了 operator== 但没同步改 std::equal_to 特化，或者哈希函数没和 operator== 保持一致（比如浮点数用 fabs(a-b) < eps 判等，但哈希却直接用 bitcast），结果就是查不到本该存在的 key。
- 最简验证方式：打印
umap.bucket_count()和umap.size()，如果后者远小于前者，说明哈希冲突严重或判等出错 - 不要用
float或double做std::unordered_map的 key，除非你完全掌控哈希和判等逻辑 - 用
std::map时，只要operator<满足严格弱序（无自反、传递、可比），就不会有这类隐式陷阱
真正难的是权衡：想快，得担 rehash 和哈希质量的风险；要稳，就得接受 log n 和额外的比较开销。选哪个，取决于你手里那块数据的真实分布、访问模式，还有上线后敢不敢为一次哈希碰撞 debug 到凌晨三点。
