选 std::map 还是 std::unordered_map，先看你的操作里有没有“按 key 有序遍历”或“范围查询”的硬需求。如果有，直接用 map；如果没有，且 key 的哈希和相等比较开销可接受，优先 unordered_map。两者的核心差异是底层结构：map 通常用红黑树，操作稳定 O(log n)，迭代器按 key 升序遍历；unordered_map 用哈希表，平均 O(1)，但最坏情况和 rehash 会影响延迟，迭代顺序不保证。选型时不要只看平均复杂度，还要看 key 类型、内存预算和延迟稳定性要求。
判断方向：需要有序遍历、范围查询（lower_bound/upper_bound）或对单次操作延迟上限敏感时选 map；只做点查、插入、删除，且能接受哈希开销和迭代顺序不确定时选 unordered_map。边界：key 的哈希函数质量差、或自定义类型未提供良好 hash 时，unordered_map 可能退化；内存紧张且元素少时，map 的节点开销未必更差，需实测。
先看操作模式：有序需求直接排除 unordered_map
如果代码里出现按 key 从小到大遍历、找第一个不小于某值的元素、或者需要稳定的迭代顺序做输出，unordered_map 无法直接满足。虽然可以拷贝到 vector 再排序，但那是额外开销，且每次遍历都要付。此时 map 的树结构天然支持有序迭代和范围查询，接口直接可用。反过来，如果只是用 key 查 value、插入新 key、删除 key，不关心顺序，那 unordered_map 的平均常数时间更合适。
一个常见误区是“元素少所以无所谓”。元素少时两者差距不明显，但代码意图清晰更重要：用 map 表达“我需要有序”，用 unordered_map 表达“我只做哈希查找”。团队 review 时，容器选择本身就是文档。
再看 key 类型：自定义类型要过哈希这一关
map 只要求 key 支持 operator< 或自定义比较器；unordered_map 要求 key 支持 std::hash 特化和 operator==。对于自定义结构体，提供小于比较通常比提供高质量哈希更容易。如果哈希函数写得随意，桶冲突会推高查找成本，平均 O(1) 的优势可能消失。C++11 起标准库为常见类型提供了 std::hash，但自定义类型需要自己补。
struct UserId {
int tenant;
int id;
bool operator==(const UserId& o) const { return tenant == o.tenant && id == o.id; }
bool operator<(const UserId& o) const { return std::tie(tenant, id) < std::tie(o.tenant, o.id); }
};
// 用 map 只需上面的 operator<
std::map<UserId, Profile> by_user;
// 用 unordered_map 还需特化 std::hash
namespace std {
template<> struct hash<UserId> {
size_t operator()(const UserId& u) const noexcept {
return std::hash<int>{}(u.tenant) ^ (std::hash<int>{}(u.id) << 1);
}
};
}
std::unordered_map<UserId, Profile> by_user_hash;如果不想写哈希，或者 key 的比较逻辑已经现成（比如来自业务排序规则），map 更省事。注意：哈希函数的质量直接影响 unordered_map 的表现，简单异或未必均匀，极端情况下可考虑组合标准哈希。
延迟与内存：平均快不等于每次快
unordered_map 的插入可能触发 rehash，导致单次操作耗时突增；map 的每次插入/查找代价稳定在 O(log n)，没有突发停顿。对延迟敏感的场景（如实时请求处理、游戏帧循环），如果无法接受偶发长尾，map 的稳定性更有价值。另一方面，map 每个节点额外存颜色和指针，内存开销通常高于 unordered_map 的桶数组加节点，但 unordered_map 的负载因子和桶数量也影响内存。元素数量很大且内存紧张时，可以调 max_load_factor 和 reserve 控制桶数量，但不要为了省内存盲目选，先估算。
如果确实需要 unordered_map 的查找速度又担心 rehash，可以在已知规模时提前 reserve，减少重哈希次数。这属于使用技巧，不改变选型结论。
实操判断清单
- 需要按 key 有序遍历或范围查询 → 选
map。 - 只做点查、插入、删除，且 key 有现成或易写的
std::hash→ 优先unordered_map。 - 自定义 key 且不想维护哈希函数 → 选
map，除非性能剖析明确指向哈希表。 - 对单次操作延迟上限敏感，不能接受 rehash 抖动 → 选
map。 - 元素数量大、内存预算紧，且能预估规模 →
unordered_map配合reserve，并实测内存。 - 不确定时，先写
map保证正确性和顺序语义，再用性能剖析决定是否换unordered_map。
最后提醒：不要因为“unordered_map 平均 O(1)”就默认它更快。实际性能取决于 key 分布、哈希质量、负载因子和硬件缓存。用真实数据做一次基准测试，比任何经验法则都可靠。
常见问题
元素很少时，选哪个有区别吗？
元素很少（比如几十个）时，两者性能差异通常可忽略。此时按语义选：需要有序用 map，否则 unordered_map 或甚至 vector 线性查找都可能更简单。不要为微小数据量引入哈希表复杂度。
unordered_map 的迭代顺序为什么每次运行可能不同？
因为哈希表按桶存储，迭代顺序取决于哈希值和桶数量，而桶数量可能随插入变化，且标准不保证顺序。如果业务依赖顺序，应改用 map 或在遍历时显式排序。