unordered_map需包含头文件，属std命名空间，底层为哈希表，平均o(1)、最坏o(n)；声明为std::unordered_map，key需支持==和哈希函数；operator[]会默认构造value，at()抛异常，insert/emplace不覆盖且返回插入结果；仅支持迭代器遍历，不维护顺序；建议预reserve避免rehash，合理设置max_load_factor优化性能。
unordered_map 的基本声明和头文件依赖
必须包含 <unordered_map></unordered_map> 头文件，且命名空间为 std。它不是传统顺序容器，不保证元素顺序，底层是哈希表实现，平均时间复杂度为 O(1) 的查找、插入、删除 —— 但最坏情况（大量哈希冲突）会退化到 O(n)。
声明格式为：std::unordered_map<key t hash keyequal allocator></key>，日常使用只需前两个模板参数：
std::unordered_map<std::string, int> word_count; std::unordered_map<int, std::string> id_to_name;
注意：Key 类型必须支持 == 比较，且必须有对应的哈希函数。内置类型（int、long、std::string 等）已提供特化，自定义结构体需手动提供 std::hash 特化或传入自定义 Hash 函数对象。
插入与访问：operator[]、insert 和 at 的区别
operator[] 最常用，但有副作用：若 key 不存在，会默认构造 value 并插入（对 int 是 0，对 std::string 是空串）。这在只读场景下容易误插脏数据。
立即学习“C++免费学习笔记（深入）”；
-
word_count["hello"]++;→ 若无 "hello"，先插入{"hello", 0}，再 ++ 变成 1 -
word_count.at("hello")→ 若 key 不存在，抛出std::out_of_range异常，适合明确要求 key 必须存在时 -
word_count.insert({key, value})或word_count.emplace(key, value)→ 不覆盖已有 key，返回std::pair<iterator bool></iterator>，second表示是否插入成功
推荐在计数类逻辑中用 operator[]，在配置加载、映射查表等关键路径中优先用 at() 或检查 insert 返回值。
遍历 unordered_map：为什么不能用下标？
unordered_map 不支持随机访问，没有 operator[] 以外的下标语法，也不能用 at(i) 或 data()。只能通过迭代器遍历：
for (const auto& pair : word_count) {
std::cout << pair.first << ": " << pair.second << "\n";
}
注意：pair.first 是 key，pair.second 是 value；若需修改 value，用 auto& 而非 const auto&；若要按 key 排序输出，得先拷贝到 std::vector 再 std::sort —— 它本身不维护顺序。
另外，迭代器失效规则比 map 更宽松：只有触发 rehash（如 rehash() 或插入导致负载因子超限）时，所有迭代器才失效；单次 insert/erase 不会使其他迭代器失效（除非 rehash 发生）。
性能调优：load_factor、reserve 和 hash 冲突处理
默认最大负载因子是 1.0，即平均每个桶最多 1 个元素。当 size() / bucket_count() > max_load_factor() 时自动 rehash，开销较大。若已知最终规模，应提前 reserve(n)（分配至少能容纳 n 个元素的桶数），而非 resize(n)（那是 vector 的）。
-
word_count.reserve(10000);→ 避免多次 rehash -
word_count.max_load_factor(0.75);→ 主动降低负载以减少冲突（但增加内存占用） - 若自定义类型作 key 且哈希分布差（如全返回 0），会导致单链过长，退化为链表查找 —— 此时必须重写哈希函数，不能只重载
operator==
调试时可打印 word_count.load_factor() 和 word_count.bucket_count() 观察实际分布。真正影响性能的往往不是哈希函数本身，而是 key 的实际分布是否均匀 —— 比如用连续整数作 key，std::hash<int></int> 是良构的；但用指针地址作 key，在 ASLR 下可能集中于某几段值域，仍需谨慎。
