因std::unordered_map封装过深，无法掌控桶扩容、哈希重算及迭代器失效等细节，故需手写散列表以满足调试、实时性或确定性内存布局需求；线性探测缓存友好但有聚集问题，链地址法删除干净但有指针开销和cache miss风险。
为什么直接用 std::unordered_map 不够，还得自己实现散列表？
因为标准库的 std::unordered_map 封装太深，底层冲突处理逻辑（如桶扩容、哈希重计算、迭代器失效规则）不可见；调试性能瓶颈、理解负载因子影响、或嵌入式/实时场景下需确定性内存布局时，必须手写。关键不是“造轮子”，而是控制——比如你得知道 rehash() 触发时是否允许拷贝构造，或 erase(iterator) 后其他迭代器是否仍有效。
线性探测法 vs 链地址法：选哪种冲突处理更贴近真实需求？
线性探测法（open addressing）缓存友好、无额外指针开销，但删除操作必须用“墓碑标记”，且聚集效应严重；链地址法（chaining）删除干净、插入稳定，但每个节点要多 8–16 字节指针开销，且链表遍历易 cache miss。实际选型看场景：
- 键值对小（如
int→int）、读多写少、内存敏感 → 用线性探测 + 增量步长（避免一次聚集） - 键类型复杂（如
std::string）、频繁增删、不介意堆分配 → 链地址 +std::vector<:list>></:list>桶数组 - 绝对不能动态分配内存（如车载系统）→ 线性探测 + 预分配静态数组 + 自定义哈希函数避免
std::hash的异常抛出
operator== 和 hash_function() 必须匹配，否则查不到数据
这是最常踩的坑：自定义类型做 key 时，如果 hash_function() 对 A 和 B 返回相同 hash 值，但 A == B 返回 false，那它们会被塞进同一桶（或同一探测序列），查找时却无法命中。正确做法是：
- 哈希函数只依赖
operator==中用到的字段（不能多，也不能少） - 若用
std::hash<t></t>特化，必须确保特化版本与operator==语义一致 - 测试用例必加：
assert(hash(a) == hash(b) ==> a == b)的反向推导不成立，但a == b ==> hash(a) == hash(b)必须成立
例如：struct Point { int x, y; }; 若 operator== 比较 x 和 y，哈希就必须用 (x * 31 + y) * 31 这类组合，不能只哈希 x。
立即学习“C++免费学习笔记（深入）”；
负载因子不是越大越好，max_load_factor(0.75) 是经验阈值
线性探测下，负载因子超过 0.7 后查找平均探查长度急剧上升；链地址法虽平缓些，但 >0.9 后单链过长，O(1) 退化为 O(n)。实操中：
- 初始化时预估容量：
reserve(expected_size / max_load_factor())，避免多次 rehash - rehash 触发后，所有迭代器失效（线性探测）或部分失效（链地址），若上层有长期持有的迭代器，必须重获取
- 不要盲目调高
max_load_factor()来“省空间”——CPU 缓存行浪费比几 KB 内存贵得多
一个典型错误是：在循环中反复 insert() 却没 reserve()，导致每插入几百个就 rehash 一次，整体性能掉 3–5 倍。
