手写哈希表的价值在于透彻理解hash计算、桶分配、冲突处理与扩容机制等底层环节，而非替代Go内置map；它揭示了运行时隐藏的细节，如负载因子、桶迁移策略及位运算索引（hash & (len-1)）等关键设计。
为什么用切片+链表实现哈希表比直接用 map 更有价值
因为 map 是 Go 运行时封装好的黑盒，底层用了开放寻址+增量扩容+cache line 对齐等优化。自己手写哈希表不是为了替代它，而是看清 hash 计算、桶分配、冲突处理、扩容时机这些环节如何联动。比如你调 make(map[int]int, 100)，根本不知道初始桶数量是多少、负载因子阈值在哪、扩容时老桶怎么迁移——这些全被隐藏了。
手写时建议从最简版本起步：固定桶数、线性探测不处理、只支持 int 键值。后续再逐步加 interface{}、链地址法、自动扩容。否则一上来就抄 runtime/hashmap.go，只会卡在 hmap 结构体的 flags 位运算和 overflow 指针链里出不来。
如何设计键值对存储结构并避免 nil panic
Go 中 map 的 key 必须可比较（==），但自定义结构体若含 slice 或 map 就不可比较。手写哈希表时，如果允许任意类型，必须用 reflect.DeepEqual 判断相等——但性能极差，且无法用于并发场景。更实际的做法是限定键为 int、string 或带 Hash() uint64 方法的类型。
- 不要用
[]struct{key int; val string}存桶，遍历时容易漏判空槽；改用[]*node，每个node显式存key和val，空槽为nil - 插入前必须检查
node != nil，否则node.key == k会 panic；读取值前也要判空，不能假设get(k)一定返回非零值 - 删除操作不是简单置
nil，得标记为deleted状态（用哨兵节点或布尔字段），否则后续get可能因线性探测中断而找不到本该存在的键
扩容时如何安全迁移旧桶而不丢数据
Go 的 map 扩容是渐进式的（边访问边迁移），但手写版用一次性迁移更直观。关键陷阱在于：新桶数量通常是旧桶的 2 倍，但旧桶中每个元素的新位置不是 hash(key) % newLen，而是 hash(key) & (newLen-1)（要求 newLen 是 2 的幂）。如果直接用取模，扩容后哈希分布会乱掉。
立即学习“go语言免费学习笔记（深入）”；
示例：旧桶长 4（mask = 3），键 k 的 hash 是 5，旧位置是 5 & 3 = 1；新桶长 8（mask = 7），新位置应是 5 & 7 = 5，而非 5 % 8 = 5 —— 这次碰巧一样，但 hash=13 时：13 & 3 = 1，13 & 7 = 5，而 13 % 8 = 5，还是相同；但 hash=12：12 & 3 = 0，12 & 7 = 4，12 % 8 = 4。看似都一致？错——当桶长不是 2 的幂时，& 和 % 行为完全不同。所以务必保证桶长始终是 2 的幂，并用位与代替取模。
- 扩容前先新建
newBuckets := make([]*node, len(h.buckets)*2) - 遍历旧桶每个非空
node，用新掩码重算位置：idx := hash(node.key) & (len(newBuckets) - 1) - 插入新桶时仍要处理冲突（线性探测或链地址），不能直接覆盖
并发读写时为什么加 mutex 还可能出问题
单纯给 Set 和 Get 加 sync.RWMutex 只能防住竞态，但掩盖了更深层问题：扩容期间，旧桶和新桶同时被读写，而 mutex 通常只锁整个哈希表。此时一个 goroutine 在旧桶删数据，另一个在新桶查数据，结果就是“删了还查得到”或“刚插进去就读不到”。
真正安全的做法是让扩容变成原子切换：先建好新桶、完成全部迁移，再用 atomic.StorePointer 替换 h.buckets 指针。但这要求所有操作都通过指针访问桶，且读操作必须用 atomic.LoadPointer 读取当前桶地址——否则 CPU 可能缓存旧指针，永远看不到新桶。
- 别在
Set里直接调resize()，应该把扩容逻辑抽成独立函数，由Set触发但不在临界区内执行迁移 - 读操作（
Get）必须用atomic.LoadPointer获取当前桶地址，然后按该桶长度计算索引，不能复用旧的h.len缓存值 - 哪怕只读，也要注意：如果桶指针已更新，但某个 goroutine 还在遍历旧桶的链表，可能读到部分迁移中的脏数据
所以，除非真需要并发安全的哈希表，否则先写单线程版本。并发的复杂度不在锁本身，而在内存可见性和状态切换的一致性上。
