unordered_map插入失效主因是键类型未正确定义哈希和相等逻辑：自定义类型须特化std::hash<T>并重载operator==；裸指针默认按地址哈希；operator[]会默认构造值且静默插入，安全查找应使用find()或at()。
unordered_map 插入元素时为什么没生效？
常见现象是调用 insert() 或 operator[] 后查不到值，或重复插入不报错但只保留一个。根本原因在于键类型没正确定义哈希和相等逻辑——尤其是自定义类型。
- 内置类型（
int、std::string）默认有哈希和==，直接可用 - 自定义结构体必须提供：① 特化
std::hash<t></t>，② 重载operator==，缺一不可 -
operator[]会默认构造值（比如int变成 0），而insert()遇到重复键直接忽略，行为差异常被误认为“失败” - 如果键是裸指针（如
const char*），默认哈希是对地址操作，不是对字符串内容——应改用std::string
查找不存在的 key 时 operator[] 会悄悄新建条目
这是最隐蔽的坑：my_map[key] 在 key 不存在时，会默认构造对应 value 并插入，同时返回这个新值的引用。你本想“查一下”，结果却意外修改了容器。
- 安全查找请用
find()或at()：auto it = my_map.find(key); if (it != my_map.end()) { ... } -
at()会抛std::out_of_range异常，适合明确要求“必须存在”的场景 -
count()只返回 0 或 1，开销略低于find()，但无法获取值引用 - 调试时注意观察 size() 变化——如果只是读操作但 size 增长了，大概率误用了
[]
unordered_map 迭代器失效的唯一时机
它不像 std::vector 那样插入就全失效，但也不是完全安全：只有 rehash 发生时，所有迭代器、引用、指针才会失效。而 rehash 触发条件是：插入后 size() > bucket_count() * max_load_factor()。
- 默认
max_load_factor()是 1.0，意味着平均每个桶最多 1 个元素；插入导致密度超标就会 rehash - 可提前预留空间避免频繁 rehash：
my_map.reserve(expected_size)—— 注意是reserve()不是resize() -
rehash(n)强制重排为至少 n 个桶，适合已知数据量且追求稳定迭代器的场景 - 删除元素、修改 value 值，都不会导致迭代器失效
性能关键：别在循环里反复调用 size() 或 empty()
虽然 size() 标准要求 O(1)，但某些老版本 libstdc++ 实现里是 O(n)（遍历桶计数）。更稳妥的做法是缓存结果或直接用 empty() 判空。
立即学习“C++免费学习笔记（深入）”；
- 循环中写
for (int i = 0; i 是危险模式，应改为 <code>const auto n = m.size(); for (int i = 0; i - 判空优先用
m.empty()，语义清晰且无兼容性风险 - 如果需要遍历全部元素，用范围 for 最自然：
for (const auto& [k, v] : m)（C++17 起支持结构化绑定） - 注意：
clear()后桶数量不归零，内存未释放；真要释放得换一个新 map 或swap空实例
哈希表的“高效”不来自语法糖，而来自你是否意识到：键的哈希质量、负载因子控制、迭代器生命周期、以及那些看似无害的 [] 操作，全都在暗处影响行为和性能。
