unordered_map查找平均O(1)但受哈希冲突、负载因子等影响可能退化至O(n)，而map稳定O(log n)且支持范围查询；延迟敏感场景优先选map，需预分配桶数、提供高质量hash，并避免operator[]误插。
unordered_map 查找快，但不是永远快
平均 O(1) 是理想情况，实际中会受哈希冲突、负载因子、key 分布影响。比如用 std::string 作 key，短字符串或大量前缀相同（如 "user_0001", "user_0002"）时，若哈希函数未充分混洗，桶内链表变长，查找退化到 O(n)。而 std::map 的 find() 始终稳定在 O(log n)，不依赖数据分布。
实操建议：
- 对延迟敏感场景（如实时音视频帧处理），优先选
std::map，避免 rehash 或冲突尖峰 - 用
std::unordered_map::reserve(N)预分配桶数，减少运行时扩容；N 至少设为预期元素数 ÷ 0.7（默认最大负载因子） - 自定义 key 类型时，别只重载
operator==，必须提供高质量 hash：冲突率高比慢更致命
map 支持 lower_bound/upper_bound，unordered_map 不行
想查 “所有 key 在 [100, 200) 范围内的 value”，std::map 只需两行：
auto it1 = m.lower_bound(100);
auto it2 = m.upper_bound(200);
for (auto it = it1; it != it2; ++it) { /* 处理 */ }
而 std::unordered_map 没有等价接口，只能全表遍历 + 条件判断，O(n) 成定局。这不是语法缺失，是哈希表结构根本无法支持范围定位。
立即学习“C++免费学习笔记（深入）”；
常见误判场景：
- 日志按时间戳分片查询（timestamp 是 key）→ 必须用
map或改用std::vector+ 二分 - 配置项按数字 ID 分组管理（ID 连续且需区间扫描）→
unordered_map会悄悄拖慢整条 pipeline - 调试时用
for (const auto& p : umap)打印，发现顺序乱 → 这不是 bug，是设计使然
插入操作的副作用差异：[] 运算符很危险
std::map::operator[] 和 std::unordered_map::operator[] 行为一致：键不存在时，**自动插入默认构造的 value**。这在计数器场景（cnt[key]++）很方便，但在只读查找逻辑里极易引入脏数据。
比如这段代码：
if (umap[key] == 0) { /* do something */ }
即使 key 原本不在容器中，也会被悄悄插入 {key, 0} —— 下次遍历时它就出现了。
安全替代方案：
- 只读查找一律用
find()：auto it = umap.find(key); if (it != umap.end()) { ... } - 需要插入但不想覆盖时，用
insert({key, value})，失败则返回pair<iterator, bool> - 明确要“有则更新、无则跳过”，用
try_emplace(key, args...)（C++17），避免重复构造 value
内存与迭代器稳定性：rehash 会让所有迭代器失效
std::map 的迭代器只要不删对应节点，就一直有效；std::unordered_map 在插入导致 size() > bucket_count() * max_load_factor() 时，会触发 rehash —— 此时所有现存迭代器、引用、指针全部失效。
这意味着：
- 不能在
for (auto it = umap.begin(); it != umap.end(); ++it)循环里调用umap.insert(...) - 缓存了某个
std::unordered_map::iterator并长期持有？得自己保证不 rehash，或改用map - 多线程下，即使只读访问，也要注意：rehash 是写操作，可能和读冲突，需加锁或用并发安全封装
真正容易被忽略的是：rehash 不是按插入次数触发，而是看负载因子。一个刚 clear() 后的 unordered_map，如果之前 reserve 过大，后续插入几十个元素就可能突然 rehash —— 这种隐式行为比性能抖动更难 debug。
