std::map 查找慢但稳定，std::unordered_map 平均快但有退化风险
选哪个不取决于“哪个更快”，而取决于你的数据规模、键分布、是否需要有序遍历，以及能否容忍最坏情况下的性能抖动。std::map 基于红黑树，std::unordered_map 基于哈希表，底层机制差异直接决定它们的适用边界。
什么时候必须用 std::map
以下场景 std::map 是更安全甚至唯一的选择：
- 需要按键有序遍历（比如用
for (const auto& p : my_map)获取升序结果） - 频繁调用
lower_bound、upper_bound或equal_range做范围查询 - 键类型没有合适的哈希函数，或自定义哈希逻辑复杂/易出错（例如嵌套结构体未正确定义
std::hash特化） - 插入/查找操作必须有可预测的上界时间 ——
std::map保证O(log n)，而std::unordered_map最坏是O(n)
std::unordered_map 的性能陷阱在哪
它不是“永远 O(1)”，实际表现高度依赖哈希质量和负载因子：
- 哈希碰撞多时（比如所有键都映射到同一个桶），查找会退化为链表遍历，变成
O(n) - 默认最大负载因子是
1.0，当元素数 / 桶数 > 1 时会触发 rehash，导致一次O(n)重建 —— 这在实时或延迟敏感场景可能引发毛刺 - 字符串键若长度很长且前缀高度重复（如 UUID 前 20 位全相同），默认
std::hash<:string>可能产生大量碰撞 - 自定义类型作键时，若
operator==和哈希函数不一致（比如哈希只看字段 A，但==还要看字段 B），会导致查不到已存在的键
// 错误示例：哈希与相等逻辑不匹配
struct Key {
int a;
std::string b;
};
namespace std::hash {
size_t operator()(const Key& k) const {
return std::hash{}(k.a); // 忽略了 b！
}
}
// 后果：Key{1,"x"} 和 Key{1,"y"} 被认为是同一个键
实测建议：小数据量别硬刚，大数据量要压测哈希
不要凭直觉猜性能。真实项目中常见反直觉现象：
立即学习“C++免费学习笔记（深入）”；
- 元素少于 50 个时，
std::map可能比std::unordered_map更快 —— 哈希计算 + 桶寻址开销超过树跳转 - 用
reserve(n)预分配桶数能显著减少 rehash 次数，但需预估容量；否则首次插入就可能触发多次扩容 - 对整数键，
std::unordered_map几乎总是赢；对长字符串键，务必用absl::Hash或自定义高效哈希（如xxh3）替代默认实现 - GCC libstdc++ 的
std::unordered_map在高冲突下比 Clang libc++ 更容易退化，跨编译器测试有必要
真正关键的不是“选哪个”，而是你是否验证过：在你的真实数据分布、线程竞争模式和内存压力下，那个“理论上快”的容器没在关键时刻掉链子。
