C#计算CRC32应使用IEEE 802.3多项式0xEDB88320查表法，初始值0xFFFFFFFF，逐字节更新后异或，最终再异或取反；推荐Span<byte>流式读取避免内存拷贝。
怎么用 C# 计算文件的 CRC32 校验和
CRC32 不是 .NET 基础类库内置的标准算法，Crc32 类需自行实现或引用第三方（如 System.IO.Hashing 预览版），但最稳妥的是手写一个兼容性好、无依赖的版本。常见错误是直接套用网络上未处理字节序（little-endian）或查表初始化错误的代码，导致结果和 cksum 或 7-Zip 不一致。
推荐使用标准 IEEE 802.3 多项式 0xEDB88320 的查表法，预生成 256 项 uint 表：
private static readonly uint[] Crc32Table = BuildCrc32Table();
private static uint[] BuildCrc32Table() {
var table = new uint[256];
for (uint i = 0; i < 256; i++) {
uint crc = i;
for (int j = 0; j < 8; j++)
crc = (crc & 1) == 1 ? (crc >> 1) ^ 0xEDB88320U : crc >> 1;
table[i] = crc;
}
return table;
}计算时注意：初始值为 0xFFFFFFFF，每字节更新后异或，最终再异或一次（即取反）：
- 读取文件用
FileStream+Span<byte>避免内存拷贝（大文件尤其重要） - 不要用
File.ReadAllBytes()加载整个文件到内存 - 若需与 Linux
cksum对齐，注意它用的是 CRC32-BZIP2（不同多项式），不是标准 IEEE 版本
Adler-32 在 C# 中怎么算才和 zlib 一致
Adler32 算法简单，但极易因溢出处理不当或初始值错位导致结果偏差。zlib 规范要求：A = 1, B = 0，且所有加法对 65521（最大质数 % 65536。
关键点：
- 必须用
uint或long累加，避免int负溢出（C# 默认不检查） - 每轮更新顺序固定：
A = (A + byteValue) % 65521，然后B = (B + A) % 65521 - 最终结果是
(B << 16) | A，不是A << 16 | B - 空文件结果应为
1（即A=1, B=0）
示例片段：
public static uint ComputeAdler32(ReadOnlySpan<byte> data) {
uint a = 1U, b = 0U;
const uint mod = 65521U;
foreach (byte bVal in data) {
a = (a + bVal) % mod;
b = (b + a) % mod;
}
return (b << 16) | a;
}为什么 System.IO.Hashing.Crc32.ComputeHash() 结果和你写的不一样
.NET 6+ 引入的 System.IO.Hashing（需安装 NuGet 包 System.IO.Hashing）中 Crc32 默认使用 Castagnoli 多项式（0x82F63B78），不是传统 IEEE 版本。这导致和大多数命令行工具、旧系统校验值不兼容。
验证方式：
- 传入单字节
0x00，IEEE 版本结果是0xD202EF8D；Castagnoli 版本是0x00000000 - 若需 IEEE 兼容，别用
System.IO.Hashing.Crc32，坚持手写查表法 -
Adler32在该命名空间中暂未提供，仍需自实现
校验和用于文件比对时，要注意哪些实际坑
单纯比对 CRC32/Adler-32 并不能完全替代哈希（如 SHA256），因为碰撞概率高——尤其是 Adler-32，对短文件或特定字节模式极不敏感。
真实场景建议：
- 局域网内快速完整性初筛（如部署包传输后校验），可用 CRC32 + 文件长度双条件判断
- 不要在安全敏感场景（如签名验证、防篡改）中单独依赖 Adler-32
- 跨平台比对前，先确认两端用的是同一多项式、同一字节序、同一初始/终值处理逻辑
- 二进制文件和文本文件无区别，但注意 Windows 下若以文本模式打开文件，可能触发
\r\n→\n自动转换，导致校验失败
最常被忽略的一点：校验和只是数值，不包含算法标识。存到数据库或配置文件时，务必同时记录算法名（如 "crc32-ieee"）、输入字节范围（是否含 BOM？是否跳过头部？），否则半年后你自己都看不懂那串数字是怎么来的。
