一、map 和 unordered_map 性能差异的根本原因
两者性能不同的本质，是底层实现的数据结构完全不同，这直接决定了它们的时间复杂度、优缺点，这是理解所有差异的核心：
std::map 底层实现
基于 红黑树 （一种自平衡的二叉搜索树），C++ 标准库的
map是有序容器（默认按 key 升序排列）。
std::unordered_map 底层实现
基于 哈希表（哈希桶） ，C++ 标准库的实现是「数组 + 链表 / 红黑树」的组合结构，是无序容器（key 的存储顺序随机，和插入顺序无关）。
二、核心性能指标对比：时间复杂度
1. 核心操作（增 / 删 / 改 / 查，单个 key）
std::map：所有操作的时间复杂度都是 O(logN) ，固定不变 红黑树的查询 / 插入 / 删除，都是通过树的二分查找实现，树的高度永远是log₂(N)级别，性能非常稳定，没有最坏情况。
补充：比如 N=1000 时，log₂(1000)≈10；N=10000 时，log₂(10000)≈14，这个计算量对 CPU 来说可以忽略不计。
std::unordered_map：平均时间复杂度 O (1) ，最坏时间复杂度 O (N)
理想情况（哈希函数足够好、无哈希冲突）：通过哈希值直接定位到哈希桶，一步找到目标 key，这是哈希表的极致性能，理论上无限快。
最坏情况（哈希冲突严重，比如所有 key 都哈希到同一个桶）：哈希桶退化成链表，查找变成遍历链表，性能暴跌。
补充：C++ 标准库的哈希函数（比如对 int/string 的哈希）设计得足够优秀，日常开发中几乎遇不到最坏情况 ，可以认为 unordered_map 的实际耗时就是 O (1) 级别。
2. 遍历操作（遍历全部 key/value）
两者的时间复杂度都是 O (N) ，没有区别；
但实际遍历速度 上，map 会略快一点点（几千量级下感知不到）：
原因：红黑树的节点是连续 / 紧凑存储的，CPU 缓存命中率更高；而哈希表的哈希桶是离散的，缓存命中率稍低，遍历的时候会有微小的性能损耗。
三、不同数据量下的性能差异
几百～几千条数据
性能几乎无差异，随便选！
- 单次查询 / 插入：两者耗时都在 纳秒～微秒级，差距在 1~10 纳秒，人类完全感知不到；
- 遍历全部数据：总耗时差距在 0.1~1 毫秒，对业务逻辑无任何影响；
- 极端测试：哪怕是 10000 条数据，两者的单次操作耗时差距也不会超过 20 纳秒。
1 万～10 万条数据
- 差异开始显现 ，
unordered_map的优势慢慢体现：单次操作耗时大概是map的 1/5 ~ 1/3； - 比如 10 万条数据，
map单次查询可能需要 20 纳秒，unordered_map只需要 5 纳秒左右； - 但这个差异依然很小，只有在「高频次循环操作」时才会有微弱的体感。
10 万条 及 百万 / 千万级数据
unordered_map 性能碾压 map，差距能达到 10 倍甚至百倍！
- 数据量越大，
logN的增长越明显，map的耗时会持续增加；而unordered_map依然保持 O (1) 的极致性能； - 比如 100 万条数据，
map单次查询可能需要 30 纳秒，unordered_map还是 5 纳秒左右； - 千万级数据下，
unordered_map的性能优势会被无限放大，这也是为什么大数据量下必选哈希表。
四、结合业务场景选择
选 std::map 的核心场景
map 的唯一核心优势：天然有序 （key 自动升序排列），基于这个特性，以下场景只能用 map：
- 业务需要有序遍历所有 key：比如你存的是「链接 - 权重」，需要按权重从小到大 / 从大到小遍历，map 直接遍历就是有序的，无需额外排序；
- 业务需要范围查询 ：比如查找
key > 100 且 key < 200的所有数据，map 提供lower_bound()/upper_bound()成员函数，能在 O (logN) 时间内完成范围查询，而 unordered_map 做范围查询只能暴力遍历所有数据（O (N)）； - 对内存占用敏感：map 是红黑树，没有内存冗余，内存占用比 unordered_map 小很多；unordered_map 是哈希表，会预分配哈希桶，有「负载因子」的内存冗余，通常内存占用是 map 的 1.5~2 倍；
- 担心哈希冲突：map 是纯树结构，没有哈希冲突的概念，性能绝对稳定，不会出现任何突发的性能暴跌。
选 std::unordered_map 的核心场景
unordered_map 的唯一核心优势：极致的单条查询 / 插入速度 ，基于这个特性，以下场景优先用
- 业务不需要有序：只需要根据 key 快速查找 / 插入 / 删除对应的 value（比如你存的是「链接 - url」，只需要通过链接 ID 快速查 url），这是最常见的业务场景；
- 未来数据量可能扩容：现在是几千条，未来可能涨到几万 / 几十万条，提前用 unordered_map，后期不用改代码，性能依然能打；
- 业务是高频的单条查询：比如循环里反复根据 key 查数据，unordered_map 的 O (1) 性能会带来微小但持续的优化。
五、unordered_map 的「性能陷阱」
坑 1：哈希冲突严重
- 原因：不同的 key 哈希后得到相同的哈希值，会落到同一个哈希桶里，哈希桶退化成链表，性能从 O (1) 暴跌到 O (N)；
- 高发场景：用自定义结构体 / 类作为 key，但没有自定义哈希函数，用了默认的哈希函数；
- 解决方案：① 对自定义 key，手写一个合适的哈希函数；② 合理设置哈希表的负载因子（默认 0.75，满 75% 就扩容，扩容会重新哈希，减少冲突）。
坑 2：频繁扩容导致性能抖动
- 原因：哈希表的容量是固定的，当元素数量达到「容量 × 负载因子」时，会触发扩容（重新申请更大的内存，把所有元素重新哈希插入），扩容过程会有短暂的性能损耗；
- 解决方案：如果知道大概的元素数量（比如你知道最多 1 万条），可以提前预留容量 ：
unordered_map.reserve(10000)，避免频繁扩容。
坑 3：key 的哈希计算耗时过长
- 原因：比如用很长的 string 作为 key，哈希函数计算哈希值的时间，可能比查找的时间还长，抵消了 O (1) 的优势；
- 解决方案：对长 string 做预处理（比如计算 md5 / 哈希值），用哈希值作为 key，而非原字符串。
注意：对于
int/short/long/普通短string这些常规 key，以上坑都不存在，放心用就行。