哈希表扩容时迭代器失效是常态，不是 bug
只要底层存储数组 realloc 或 new 新内存，所有指向旧桶的 iterator、const_iterator、甚至 pointer 都会失效。C++ 标准库的 std::unordered_map 也这样，别试图“保活”迭代器。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 扩容前，若业务逻辑正在遍历，必须先完成遍历或缓存 key，再触发插入/扩容
- 不要在循环中边遍历边
insert()或erase()，容易踩空指针或越界读 - 若需稳定迭代，可先用
std::vector<:pair v>></:pair>拷贝当前全部元素，再操作原表
负载因子阈值选 0.75 还是 1.0？看冲突容忍度
负载因子（size() / bucket_count()）决定何时扩容。选 0.75 是为了平衡空间和查找性能：超过后链地址法平均链长快速上升，find() 退化为 O(n)；选 1.0 节省内存但冲突剧增，尤其在哈希函数不理想时。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用
std::hash<K>默认实现时，保守取0.75；若 K 是整数且分布均匀，可放宽到0.9 - 缩容阈值别设成扩容阈值的一半（比如 0.75→0.375），否则在临界 size 反复扩缩——推荐缩容触发点设为扩容阈值的 1/4（如 0.75→0.1875）
- 缩容后记得调用
rehash()或手动重建桶数组，避免空桶残留拖慢遍历
自定义哈希函数和等价判断必须满足传递性
如果重载 operator== 或提供 EqualKey 仿函数，它必须满足：若 a == b 且 b == c，则 a == c。否则 find() 可能漏匹配，erase(key) 删不干净。
常见错误现象：
- 用浮点数做 key 时，按
abs(a - b) 判断相等 → 不满足传递性（a≈b、b≈c 不保证 a≈c） - 字符串忽略大小写比较，但哈希函数仍用原始字节 → 哈希值不同，相同语义 key 被分到不同桶
- 结构体比较只看部分字段，但哈希函数用了全部字段 → 同 key 不同 hash，查不到
务必让 Hash::operator()(k) 和 EqualKey::operator()(a, b) 基于同一组语义字段计算。
移动语义对 value_type 的要求常被忽略
动态扩缩容要重新散列所有元素，涉及大量 std::move() 和 placement-new。若 V 类型没有移动构造函数，或移动后状态不可预测（比如移动后 v.size() 不为 0），扩容过程可能崩溃或数据错乱。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对自定义类型
V，显式声明V(V&&) = default，并确保移动后对象处于有效但未指定状态 - 避免在
V的移动构造里抛异常；如有必要，用noexcept标记，否则rehash()可能因异常安全策略降级为拷贝 - 测试时用
std::vector<std::string>和std::unique_ptr<int>混合插入，观察扩容是否静默失败
真正麻烦的从来不是怎么分配新桶，而是 value 的生命周期管理细节一旦没对齐，问题只在高并发或大负载时浮现。
