std::hash返回值不能直接作下标因size_t远超容量，取模易放大冲突；需质数容量、哈希扰动（如异或右移）、避免string哈希直接线性探测；vector桶优于list但限均长≤4；扩容必重建索引且容量仍为质数；删除与rehash是关键难点。
开放寻址法里 std::hash 的返回值为什么不能直接当数组下标？
因为 std::hash 返回的是 size_t，通常远大于哈希表容量，直接取模容易放大哈希冲突——尤其当容量不是质数时，低位重复模式会暴露出来。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 容量必须选质数（比如 101、1009、10007），避免与常见哈希值的低位周期共振
- 用
hash(key) % capacity前，先对hash(key)做一次扰动：比如(hash(key) ^ (hash(key) >> 16)) % capacity，打散低位相关性 - 别用
std::hash<:string></:string>直接喂给线性探测——它在短字符串上输出高度集中，实测冲突率比扰动后高 3–5 倍
链地址法中 std::list 和 std::vector 哪个更适合作桶？
多数情况选 std::vector，但前提是预估单桶平均长度 ≤ 4；否则插入/删除开销变大，缓存局部性反而下降。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 桶内元素少（如负载因子 std::vector<:pair>>
- 桶内元素多、高频增删、键类型构造成本高 → 改用
std::forward_list（比std::list少一半指针开销） - 别在桶里存裸指针：
std::vector<:unique_ptr>></:unique_ptr>比std::vector<node></node>更安全，且移动时零拷贝
开放寻址法遇到 DELETED 标记位时，查找和插入逻辑怎么写才不漏？
标记已删除位置不是“空位”，而是“可覆盖但不可终止查找”的中间态。线性探测中跳过它继续找，但插入时优先填这里。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 查找循环里，遇到
EMPTY立即退出；遇到DELETED继续走；只在OCCUPIED且 key 匹配时返回成功 - 插入时，记录第一个
DELETED位置，若最终没找到匹配 key，则填到该位置；若全程无DELETED，才填到最后一个EMPTY - 别用布尔值表示三种状态——用枚举
enum class State { EMPTY, DELETED, OCCUPIED };，避免误判true/false含义
std::unordered_map 的 rehash() 触发条件和自定义表怎么对齐？
标准库在 size() > bucket_count() * max_load_factor() 时触发扩容，而默认 max_load_factor() 是 1.0。你手写的表如果设成 0.75，但没重算桶索引，就会提前假满。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 每次
rehash()必须重建所有桶：旧数据逐个insert()到新表，不能 memcpy - 扩容后容量必须仍是质数——别用
old_cap * 2，查预计算质数表或用静态数组{2, 3, 5, 11, 23, 47, 97, ...} - 把
max_load_factor设为成员变量，且在insert()结尾显式检查：if (size() > capacity_ * load_factor_) rehash(next_prime(capacity_));
真正麻烦的从来不是哈希函数本身，而是删除后如何维持探测序列连续性，以及扩容时怎么让每个键重新落进合理桶里——这两处一错，表就 quietly 开始降速甚至漏数据。
