需为unordered_map自定义哈希函数和operator==：哈希函数须重载operator()返回size_t且等键同哈，推荐用std::hash分别哈希各字段再位移异或混合；operator==必须正确定义，确保与哈希逻辑一致，否则find()总返回end()。
怎么给 unordered_map 写自定义哈希函数
直接写一个满足 std::hash 概念的仿函数（functor）或 lambda（C++20 起支持），然后作为第三个模板参数传进去。核心是重载 operator()，返回 size_t，且对相等的键必须返回相同值。
常见错误：只用 std::hash 组合成员却忽略顺序或溢出——比如对 pair<int int></int> 直接 a ^ b，会导致 (1,2) 和 (2,1) 哈希冲突；或者用乘法不加掩码，导致高位丢失影响分布。
- 推荐做法：用
std::hash<t>{}(x)</t>分别哈希各字段，再用位移+异或混合，例如(h1 或更鲁棒的 <code>h1 ^ (h2 > (sizeof(size_t)*8 - 13)) - 如果键是自定义 struct，必须同时提供自定义
operator==，否则unordered_map查找会失败（它靠哈希分桶 + 桶内线性比较） - C++20 可用
auto推导 lambda，但注意捕获为空，且不能含运行时状态；编译期固定的结构体建议用 constexpr 哈希（需 C++23 或手动实现）
unordered_set 插入慢？先检查哈希碰撞和负载因子
插入变慢通常不是哈希函数本身慢，而是哈希分布差 → 桶内链表/红黑树过长 → 平均查找/插入退化为 O(n)。用 load_factor() 查看当前负载（size() / bucket_count()），超过 1.0 就容易出问题。
典型场景：大量字符串键以相同前缀开头（如 "user_1", "user_2"），若哈希函数未充分打散低位，所有键挤进少数桶里。
立即学习“C++免费学习笔记（深入）”；
- 调用
rehash(n)手动扩容（n 设为略大于size() * 1.5的质数），避免反复触发默认重哈希 - 避免用
reserve()代替rehash()：前者只预分配内存，不重建桶数组；后者才真正重排哈希表结构 - GCC libstdc++ 默认最大负载因子是 1.0，Clang libc++ 是 1.25，跨平台项目建议显式设
max_load_factor(0.75)提前干预
struct 当 key 时，为什么 find() 总是返回 end()
90% 是因为没正确定义相等比较：哈希函数只是分桶依据，最终确认是否“是同一个 key”靠的是 key_equal 函数对象（默认 std::equal_to<key></key>）。如果你的 struct 没重载 operator==，就只能靠默认的逐字节比较——而一旦有 padding 字节、指针或浮点成员，结果不可控。
错误现象：my_map.find(my_key) == my_map.end() 即使刚用同样值插入过。
- 必须确保自定义
operator==与哈希逻辑一致：若哈希把a.x和a.y都纳入计算，则==也必须比较这两个字段 - 不要在
operator==里做浮点近似比较（如abs(a - b) ），哈希表不支持“模糊相等”——它要求严格二元等价关系 - 若 struct 含
std::string或容器，编译器生成的默认==通常够用；但含裸指针、std::unique_ptr或自定义内存管理时，必须手写
哈希函数里用 std::hash 组合多个字段，要注意什么
标准库的 std::hash 对基础类型安全，但组合时容易踩两个坑：一是未处理字段顺序敏感性，二是未防止哈希值被截断或符号扩展。
例如对 struct { int a; short b; }，直接 h1 ^ h2 会让 b 的高位信息几乎丢失；若用 (h1 * 31) + h2，又可能因乘法溢出导致分布恶化。
- 优先用
std::hash对每个字段分别求哈希，再用位运算混合：推荐(h1 ^ (h2 或 Boost 风格的 <code>h1 ^ (h2 + 0x9e3779b9 + (h1>2)) - 避免对
char*直接用std::hash<const char></const>——它哈希的是指针地址，不是字符串内容；应转成std::string_view或用std::hash<:string_view></:string_view> - 如果字段含
float或double，先用std::bit_cast<uint32_t>(f)</uint32_t>（C++20）转整型再哈希，避免 NaN、-0.0 等特殊值引发不一致
哈希函数写得再漂亮，只要 operator== 和它不匹配，整个容器就不可用。这两者必须当成一个契约来维护，而不是两个独立任务。
