底层开发中不能直接用 std::unordered_map，因其内存布局、扩容策略和哈希函数绑定不可控；需自实现以支持自定义对齐、内存池复用及no-std环境。
为什么不能直接用 std::unordered_map？
底层开发场景下，std::unordered_map 的内存布局、扩容策略、哈希函数绑定方式往往不可控——比如你要对 key 做自定义对齐、复用已有内存池、或在 no-std 环境里运行。它封装太深，rehash 触发时机、桶数组分配路径、冲突链组织形式都藏在实现细节里，没法按需裁剪。
所以得自己写：核心是管住三件事——桶数组指针、元素数量、负载因子阈值；其余都是围绕这三者的响应逻辑。
resize() 触发条件与安全扩容步骤
自动扩容不是“满了就扩”，而是当 size() / bucket_count() >= max_load_factor 时才触发。关键陷阱在于：扩容必须原子完成，否则迭代器失效、并发访问会读到半新半旧的桶指针。
- 先申请新桶数组（大小通常翻倍，如
new_bucket_count = old_count * 2），用operator new或指定 allocator 分配 - 逐个 rehash 现有元素到新桶——注意：不能边遍历旧桶边插入新桶，要先建好空桶，再迁移；否则哈希冲突链可能被意外截断
- 迁移完成后，用
std::atomic_store（多线程）或简单指针交换（单线程）切换m_buckets指针 - 旧桶数组必须延后释放，确保所有正在执行的
find()已完成——这是最容易漏掉的生命周期管理点
哈希冲突处理选开放寻址还是拉链法？
底层开发中，开放寻址（如线性探测）局部性好、缓存友好，但删除操作麻烦；拉链法（每个桶是 node* 链表）实现简单、删除自由，但指针跳转多、内存不连续。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
如果你控制内存分配器，推荐带惰性删除的开放寻址：enum class BucketState { EMPTY, OCCUPIED, DELETED }。DELETED 桶允许后续插入，又不影响查找终止条件。
拉链法常见错误是忘了把 node 内存和桶数组解耦——否则 resize 时要么复制整个 node（破坏 aliasing），要么只挪指针（但 node 分散在堆上，迁移无意义）。
迭代器失效边界在哪？
只要没调用 resize()，开放寻址表的迭代器就是稳定指针（指向桶内原位置）；拉链法下，只要 node 不被 delete，迭代器也有效。真正危险的是用户在遍历时隐式触发扩容——比如在 for (auto it = begin(); it != end(); ++it) 循环里调了 insert()。
- 明确文档约束：不保证遍历中插入的安全性
- 如果必须支持，迭代器内部得存“当前桶索引 + 当前探查步数”，而不是裸指针
- 更现实的做法是：在 debug build 中用
assert(m_resize_counter == m_last_seen_counter)捕获误用
真正的复杂点不在怎么写 resize，而在怎么让使用者清楚知道——哪次操作会重排内存、哪次只是改标记、哪次连标记都不动。这些边界一旦模糊，调试成本远超实现本身。
