Go map通过tophash高8位快速筛选槽位，跳过不匹配key的完整比对；溢出桶按需创建，但大初始桶数会预分配；哈希分布不均导致CPU飙升主因是key比对爆炸。
Go map 查找时如何快速跳过不匹配的 key
它不直接比对完整 key，而是先用 hash 值的高 8 位查 tophash 数组——每个 bucket 有 8 个槽位，对应一个长度为 8 的 tophash 数组。只要 tophash[i] 不等于目标 hash 的高 8 位，就跳过该槽位，完全不触发 key 比较。
这个设计把大部分无效比对挡在门外。实测中，哪怕 bucket 溢出链很长，只要 tophash 分布合理，runtime.mapaccess1 的 CPU 占比就能压下来。
- 注意：
tophash只存高 8 位，不是全 hash，所以无法靠它唯一判定相等，只能做“粗筛” - 如果大量 key 的 hash 高 8 位相同（比如 string 字段总是
"user:" + id），tophash失效，所有槽位都得走完整比对路径 - Go 1.24+ 的 Swiss Tables 用 control byte 替代了
tophash，但“高位粗筛”逻辑没变，只是匹配更快
溢出桶（overflow bucket）什么时候被创建
每个 bucket 固定最多存 8 对 key-value；第 9 个冲突 key 进来时，运行时会分配一个新 bmap 作为 overflow bucket，并用 overflow 指针链上去。这不是预分配，而是按需创建。
但有个例外：当 map 初始桶数 ≥ 2⁴（即 16），运行时会预分配 2^(B−4) 个 overflow bucket（B 是当前桶数量的 log₂），放在常规 bucket 内存块之后，减少频繁 malloc。
- 溢出桶结构和普通 bucket 完全一样：仍有自己的
tophash[8]、data 区、甚至可能再挂下一个 overflow bucket - 查找时，runtime 会顺着 overflow 链一直往下扫，直到找到或链尾 —— 这就是 O(n) 退化的主因
- 别以为“小 map 就不会溢出”：struct 中
float64字段含-0.0和0.0，哈希值不同但语义相等，极易在同一个 bucket 堆出长链
为什么 runtime.mapaccess1 在火焰图里占满 CPU
这不是 map 本身慢，而是 key 比对开销爆炸。典型信号是火焰图里 runtime.mapaccess1 下堆着大量 memequal 或 memcmp 调用。
根本原因只有两个：要么单个 bucket 内有效槽位太多（tophash 筛不动），要么 overflow 链太长，导致每次查找都要逐个比对 key 字节。
- 常见诱因：
struct{ ID int; Name string }中Name总是空或固定前缀，高位 hash 塌缩到同一值 -
[]byte、map、指针字段虽被编译器禁止作 key，但嵌套在 struct 里（如*int）可能逃过检查，却导致哈希失衡 - 用
fmt.Sprintf拼 key：每次生成新字符串对象，哈希计算多一层，且字符串头逃逸到堆，干扰 GC
sync.Map 并不能缓解哈希冲突
sync.Map 的 read map 和 dirty map 底层仍是原生 map，哈希函数、bucket 结构、冲突处理逻辑全部未变。它只解决并发读写安全问题，不碰哈希质量。
LoadOrStore 在 key 不存在时还会深拷贝 value；如果 value 是大 struct，冲突没解，反而新增内存压力。
- 小 map（len sync.RWMutex 的普通 map 吞吐常高于
sync.Map - 真正要降冲突，必须动 key 类型：UUID 改用
[16]byte，float64字段转math.Float64bits(x)，避免 struct 含可变长字段 - 别依赖 pprof 看
len(m)—— 要看runtime.ReadMemStats().MapHashSys / MapBuckets比值，> 2 就说明溢出桶泛滥
MapBuckets 的实际数量双向印证，而不是盯着代码里那行 make(map[string]int)。 
