HashMap扩容时会重新计算哈希值并重分布key，翻倍扩容使桶数加倍、高位参与定位，等量扩容则重置seed强制全量rehash以打散局部碰撞，二者均调用hashGrow但机制不同。
扩容时哈希值重算是否改变 key 分布
会，而且这是等量扩容（samesizegrow）的核心目的。翻倍扩容和等量扩容都调用 hashgrow，但只有等量扩容会强制对所有 key 重新哈希——哪怕桶数量不变（b 不变），hmap.seed 也会被重置，导致每个 key 的完整 hash 值变化，从而打散原本集中在少数 bucket 的 key。
常见误判是认为“桶数没变，key 肯定还落在老位置”。实际不是：旧 bucket 中的 key 搬到新 bucket 时，要重新计算 hash & (2^B - 1)，而新 seed 让结果完全不同。这能缓解因初始哈希不均（比如 struct 中 string 字段全为空）导致的局部碰撞。
- 翻倍扩容：桶数从
2^B→2^(B+1)，高位多一位参与取模，自然分散 - 等量扩容：桶数不变，但
hash0重置 + 全量 rehash，靠随机性破局 - 如果 key 含
float64且含NaN，重哈希后仍无法查到——这不是扩容问题，是 key 本身不满足相等一致性
扩容中查找 key 为什么还要查 oldbuckets
因为迁移是渐进的，hmap.oldbuckets != nil 就表示扩容未完成。此时查找逻辑是：先按新 hash 路径查 buckets，若未命中，再用旧 hash 路径查对应 oldbuckets 中的 bucket。这保证了语义正确性，但代价是每次查找多一次指针跳转和条件判断。
容易被忽略的是：即使你只读不写，只要 oldbuckets 还在，查找就永远多这一层开销。而 nevacuate 只在写操作或迭代时推进，纯读场景下扩容可能“卡住”很久。
- 火焰图里看到
runtime.mapaccess1下有大量bucketShift或bucketShiftOld调用，基本说明正处在扩容中 -
runtime.ReadMemStats中MapBuckets和MapHashSys差值变大，也暗示 oldbuckets 占着内存没释放 - 别依赖
len(m)判断是否扩容完成——它只反映元素数，和oldbuckets == nil无关
溢出桶过多触发等量扩容的真实影响
noverflow > 2^15（即 >32768）是硬编码阈值，但它是个近似计数：只增不减。哪怕你删光所有元素，只要历史上分配过这么多溢出桶，noverflow 仍维持高位，下次写入就立刻触发等量扩容。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
这种场景下，map 表面看 len(m) 很小，但内存占用高、CPU 耗在搬迁上——本质是“碎片整理”，用 CPU 换访问稳定性。如果你观察到频繁的 mapassign 日志（加 GODEBUG=gctrace=1），且 len(m) 波动不大，大概率就是这个原因。
- struct 作 key 时字段取值高度重复（如
Name总是""或"user"），会导致 tophash 高位塌缩，加速溢出桶堆积 - 预分配不能解决此问题：
make(map[K]V, 1000)只影响初始桶数，不影响后续溢出桶分配策略 - 验证方式：pprof 抓 CPU，若
runtime.evacuate占比异常高，且runtime.mapaccess1调用频次同步上升，就是等量扩容在持续工作
为什么 map 扩容不解决所有哈希碰撞
扩容只能缓解由「桶密度」引发的碰撞，对「key 本身哈希质量差」无能为力。比如 struct{ ID int; Ts float64 } 中 Ts 是未归一化的 NaN 或 -0.0，两次插入生成不同 hash，它们根本不会落在同一个 bucket，扩容也救不了查找失败。
真正难调的是这种隐性问题：程序不 panic、不报错，只是部分 key 查不到或性能忽高忽低。它不体现在 loadFactor 或 noverflow 上，得从 key 字段的取值分布反推。
- 用
math.Float64bits(x)替代裸float64字段，把 NaN/-0.0 显式转成整数位模式 - UUID 优先用
[16]byte而非string，省掉字符串头和 runtime 哈希路径 - 自定义类型实现
Hash方法时，必须确保相同逻辑值 → 相同 hash，且不依赖指针地址或运行时状态
