直接用zlib的crc32()函数最稳，需传入初始值0xffffffffu并异或0xffffffffu得最终结果；adler32更快但抗碰撞性差，仅适用于弱校验场景。
CRC32校验和计算：用zlib还是自己手写？
直接用zlib的crc32()函数最稳，别自己重实现——标准CRC32算法对初始值、多项式、字节序、翻转规则极其敏感，手写极易和主流工具（如cksum、gzip）结果不一致。
常见错误现象：crc32(buf, len)返回值和命令行cksum -o3或Python zlib.crc32()对不上，大概率是初始值设成了0而非0xFFFFFFFF，或没做末尾异或0xFFFFFFFF。
- 必须传入初始值
0xFFFFFFFFU，不能用0 - 计算完要再异或
0xFFFFFFFFU，才是最终校验和 -
zlib头文件是<zlib.h></zlib.h>，链接时加-lz
#include <zlib.h>
uint32_t calc_crc32(const uint8_t* data, size_t len) {
return crc32(0xFFFFFFFFU, data, len) ^ 0xFFFFFFFFU;
}
Adler32为什么比CRC32快但慎用于校验？
Adler32本质是两个16位累加器（A和B）滚动更新，无查表、无位运算，CPU缓存友好，速度通常是CRC32的2–3倍。但它对短数据、特定模式（比如连续零字节）极不敏感，碰撞概率远高于CRC32，**只适合快速完整性预检，不能替代CRC做可靠校验**。
使用场景：HTTP/1.1中Content-Encoding: identity的弱校验、内存受限嵌入式设备的轻量级校验。
立即学习“C++免费学习笔记（深入）”；
- zlib里对应函数是
adler32()，参数顺序和crc32()一致 - 初始值必须是
1，不是0；无需末尾异或 - 输入为空时返回
1，不是0
uint32_t calc_adler32(const uint8_t* data, size_t len) {
return adler32(1, data, len); // 注意：初始值是1
}
二进制数据传入时字节序和const限定容易出错
所有zlib校验函数都按字节流处理，不关心int或struct的内存布局，所以传uint8_t*最安全。若你有std::vector<uint8_t></uint8_t>或std::string，直接取.data()即可；若用std::vector<int></int>之类，必须先reinterpret_cast<const uint8_t></const>，否则会把每个int当4个独立字节喂进去，结果完全不可控。
-
std::string含\0时，务必用.data()+.size()，别用.c_str() - 传
const uint8_t*，避免编译器警告或隐式转换问题 - 不要对指针做
+1偏移后直接传长度，容易越界
性能与兼容性：CRC32硬件指令能用吗？
现代x86-64（SSE4.2+）和ARMv8-A有crc32b/crc32w等指令，zlib默认不启用——它走纯C实现以保证跨平台一致性。想用硬件加速得换库（如intel-ipsec-mb）或自己内联汇编，但代价是失去可移植性，且对小块数据（
真正影响性能的是数据分块方式：一次喂1MB比循环喂1KB快得多，因为函数调用和分支预测开销被摊薄了。
- 单次调用处理尽可能大的连续内存块
- 避免在循环里反复调用
crc32()处理单字节 - 如果必须增量计算，用
crc32(crc, data, len)链式传入上一轮返回值
校验和这东西，差一个字节、一个初始值、一个异或，结果就全错；而这种错往往静默发生，直到线上数据损坏才暴露。盯紧0xFFFFFFFFU和1这两个魔数，比优化算法重要得多。
