std::hash不够快因其采用简单遍历+乘加，无simd加速与分块并行，1kb以上字符串吞吐不足murmurhash3的1/3，且跨平台哈希值不一致，影响缓存、序列化及分布式场景。
为什么直接用 std::hash 不够快？
标准库的 std::hash<:string></:string> 在多数编译器里是简单遍历 + 乘加，没有 SIMD 加速，也没有针对长字符串做分块并行处理。对 1KB 以上的字符串，吞吐量常不到 MurmurHash3 的 1/3。更关键的是它不保证跨平台一致性——同一字符串在 GCC 和 MSVC 下可能得到不同哈希值，这对缓存键、序列化或分布式场景是硬伤。
MurmurHash3_x64_128 的 C++ 实现要点
官方 C 版本（MurmurHash3.h）可直接用于 C++，但要注意几个实操细节：
- 必须传入
const void*指针和size_t长度，不能直接传std::string—— 要用s.data()和s.size() - 种子（
seed）建议固定为 0 或 0xdeadbeef，避免无意中引入随机性导致哈希不稳定 - 输出是 128 位（4 个
uint32_t），若只需 64 位，取低半部分即可，别用异或合并——会破坏 avalanche effect - 对空字符串，官方实现返回全 0，这点和某些自定义哈希不同，需确认业务是否接受
示例调用：
uint32_t out[4]; MurmurHash3_x64_128(s.data(), s.size(), 0, &out);
如何避免字节序和对齐踩坑？
原版 MurmurHash3 假设小端序、自然对齐访问。在 x86/x64 上没问题，但在 ARM64 或某些嵌入式平台可能触发未对齐访问异常或性能下降：
- 不要把
char*强转成uint64_t*直接读 —— 改用memcpy提取 8 字节块（编译器通常能优化掉） - 检查目标平台是否定义了
__aarch64__，若是，启用MURMURHASH_NO_UNALIGNED宏（需手动 patch 头文件） - 字符串末尾剩余 1–7 字节时，官方用 switch-case 逐字节处理，这部分无法向量化，但影响极小，不必重写
性能对比时容易忽略的点
实测发现很多人 benchmark 结果失真，问题出在：
- 没禁用 ASLR 和 CPU 频率调节：
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space，并用cpupower frequency-set -g performance - 用短字符串（如 8 字节）测试，此时 MurmurHash3 的初始化开销占比高，反而不如简单循环
- 忘了关闭编译器自动向量化干扰：加
-fno-tree-vectorize确保对比的是算法本身，不是编译器优化差异 - 没预热 CPU 缓存：先跑 1000 次再计时，否则第一次访问 L3 缓存 miss 严重拉低分数
真正影响落地效果的，往往是内存布局连续性——把待哈希的字符串批量放在一起，比单个 std::string 对象反复构造/析构快得多。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
