Go runtime 字符串哈希不是 FNV-1a，自1.18起改用自研memhash变种，基于memhash64并依赖CPU指令，不可预测、抗碰撞且每次运行因hash0种子不同而结果不同。
Go runtime 中字符串哈希用的是 FNV-1a 吗？
不是。Go 1.18 之后已弃用 FNV-1a，改用自研的 memhash 变种（基于 memhash64），底层调用 CPU 指令如 POPCNT、CLMUL 或 fallback 到纯 Go 实现。它不再是可预测的 FNV 迭代，而是分块处理 + 种子扰动，目标是抗碰撞和防哈希洪水攻击。
你不能在用户代码中直接调用该函数——它被标记为 //go:linkname，仅限 runtime 内部使用。比如 runtime.memhash 的签名是：
func memhash(p unsafe.Pointer, h, s uintptr) uintptr
其中 p 是字符串底层数组指针，h 是 hash0 种子（来自 hmap.hash0），s 是字符串长度。
为什么字符串哈希结果每次运行都不一样？
因为每个 map 实例初始化时，会从系统随机数生成器取一个 32 位 hash0 值存入 hmap.hash0 字段。这个种子参与所有键的哈希计算，包括字符串。所以即使相同字符串，在不同 map 或不同进程里算出的桶索引也不同。
立即学习“go语言免费学习笔记（深入）”；
这带来两个实际影响：
- 无法跨进程或序列化后复现哈希分布（比如调试时打印 bucket 索引无意义）
-
map遍历顺序随机化，本质就是 hash0 打乱了键到桶的映射关系 - 若需稳定哈希（如一致性哈希场景），必须自己实现并绕过 runtime 哈希，例如用
hash/fnv或hash/maphash
如何在用户代码中获得与 runtime 一致的字符串哈希？
做不到完全一致，但可以高度逼近：用 hash/maphash 包。它是 Go 官方提供的、与 runtime 哈希算法同源的用户侧接口，接受自定义 seed，且默认启用相同指令优化。
示例：
import "hash/maphash"
h := maphash.Hash{}
h.SetSeed(maphash.MakeSeed()) // 或固定 seed 用于可重现性
h.Write([]byte("hello"))
keyHash := h.Sum64() // 与 runtime 对同一字符串的计算逻辑高度一致
注意：maphash 不等于 runtime.memhash —— 它不读取 hmap.hash0，也不处理 nil 字符串边界；但它是最接近、最安全的替代方案。
字符串哈希性能关键点：小字符串 vs 大字符串
runtime 对字符串做了路径优化：
- 长度 ≤ 32 字节：走 fast path，用 unrolled load + 混淆异或，几乎常数时间
- 长度 > 32 字节：分块（通常 32B/块）调用
memhash64，最后再混合一次 - 空字符串
""不是特例，仍参与完整哈希流程（只是输入长度为 0） - 避免在 hot path 上反复构造新字符串（如
s[:n]）作为 map key，因为每次都会触发完整哈希计算
真正容易被忽略的是：字符串 header 中的指针和长度字段本身不参与哈希，只有底层数组内容被读取。这意味着两个不同变量但指向同一底层数组的字符串（如切片得到的子串），只要内容一致，哈希值就一致——这是符合预期的，但有时会被误认为“引用相等才哈希相等”。
