XXH64流式校验比MD5/SHA256快5–8倍，但需用XXH64_state_t分块处理：初始化状态、循环update、最后digest；块大小宜选64KB并内存对齐；Clang -Ofast编译比GCC -O3快8–12%，且须预定义XXH_INLINE_ALL宏。
大文件校验用 XXH64 比 MD5 或 SHA256 快 5–8 倍，但直接调用不等于快——关键在分块策略、状态复用和编译器优化。
为什么不能直接用 XXH64 一次性读整个文件
看似简单：fread 全部内容进内存再喂给 XXH64，实际会崩：
- 10GB 文件在 32 位或内存受限环境直接
malloc失败 - 即使成功，
XXH64(const void*, size_t, XXH64_hash_t)是单次全量计算，无法流式处理，失去对超大文件的适应性 - 频繁分配/释放大缓冲区触发
malloc碎片与系统调用开销，反而拖慢吞吐
必须用 XXH64_state_t 流式计算
真正高性能路径是初始化一次状态，循环喂数据块，最后萃取结果。这是唯一能压榨出 xxHash 极致吞吐的方式：
-
XXH64_createState()分配内部状态（约 200 字节），不是每次调用都 malloc -
XXH64_reset(state, seed)清空并重置，支持多文件复用同一 state 对象 -
XXH64_update(state, buffer, len)是核心：只拷贝指针+长度，无内存复制，CPU 缓存友好 -
XXH64_digest(state)最后一步，仅做最终混合，毫秒级
示例关键片段：
立即学习“C++免费学习笔记（深入）”；
XXH64_state_t* state = XXH64_createState();
XXH64_reset(state, 0);
size_t n;
while ((n = fread(buf, 1, CHUNK_SIZE, fp)) > 0) {
XXH64_update(state, buf, n);
}
XXH64_hash_t hash = XXH64_digest(state);
XXH64_freeState(state); // 别漏掉
块大小设多少？别迷信默认值
实测中 CHUNK_SIZE 不是越大越好，也不是越小越稳：
- 64KB（
65536）适合 SSD + 小文件（ - 4MB（
4194304）是大文件（>10GB）吞吐峰值点，减少XXH64_update调用次数，提升 CPU 指令级并行利用率 - 超过 8MB 后，单次
fread可能阻塞更久，且缓存局部性下降，Clang/GCC 向量化收益衰减 - 务必对齐：用
posix_memalign或_aligned_malloc分配缓冲区，避免非对齐访问惩罚（尤其 AVX2 指令路径）
Clang vs GCC 编译时的性能落差在哪
同一段流式代码，Clang -Ofast 编译后比 GCC -O3 快 8–12%，差异不在算法，而在底层指令生成：
- Clang 更激进地将
XXH64_update内循环向量化为 AVX2 指令（如vpaddd,vpshufb），GCC 默认保留更多安全检查 - Clang 对
xxh_x86dispatch.c中 CPU 特性检测分支做了更优的预测提示，减少分支误判惩罚 - 若用 GCC，需显式加
-march=native -funroll-loops才接近 Clang 表现；Clang 的-Ofast已隐含这些 - 注意：
-Ofast禁用 IEEE 浮点约束，但 xxHash 不涉及浮点，可放心用
真正容易被忽略的是：XXH_INLINE_ALL 宏必须在 #include "xxhash.h" 前定义，否则内联失效，函数调用开销立刻吃掉 15% 吞吐。这个细节连很多 xxHash 文档都没强调清楚。
