Go标准库中CRC32应使用crc32.New(crc32.IEEE)创建新实例并调用Write/Sum32，避免复用未Reset的哈希；CRC64无Sum64顶层函数，须用crc64.New+Write+Sum64；io.Copy校验需检查错误并确保文件从头读取。
Go 标准库怎么算 CRC32？别直接用 hash/crc32.Sum32()
直接调 hash/crc32.Sum32() 容易出错——它只接收 []byte，但内部没重置状态，连续调用会把前一次结果累加进去。实际你要的是“对一段数据独立计算”，不是流式追加。
正确做法是用 hash/crc32.New() 拿个新哈希实例：
h := crc32.New(crc32.IEEE)
h.Write([]byte("hello"))
sum := h.Sum32() // uint32 类型，不是 []byte
-
crc32.IEEE是最常用多项式，兼容大多数协议（如 ZIP、PNG）；如果协议指定其他多项式（比如crc32.Koopman），必须显式传入 - 别忘了
h.Reset()—— 复用同一个hash.Hash实例前必须重置，否则结果叠加 -
Sum32()返回uint32，而Sum(nil)返回[]byte（4 字节大端），二者值相等但类型不同，别混用
为什么 crc64 不像 crc32 那样有 Sum64() 便捷函数？
因为 hash/crc64 设计上更保守：它不提供类似 Sum64() 的顶层函数，只暴露 New() 和接口方法。这不是遗漏，是避免用户误以为存在“无状态单次计算”捷径。
要算一次 CRC64，必须走标准 hash.Hash 流程：
立即学习“go语言免费学习笔记（深入）”；
h := crc64.New(crc64.ISO) // 或 crc64.ECMA
h.Write([]byte("world"))
sum := h.Sum64() // uint64
-
crc64.ISO和crc64.ECMA是两个主流表，互不兼容；选错会导致校验失败，得看协议文档确认 - 没有
crc64.Sum64(data)这种函数，强行封装要注意：每次都要新建hash.Hash，不能复用未Reset()的实例 - CRC64 计算比 CRC32 慢约 1.5–2 倍（尤其小数据），如果高频短内容校验，先评估是否真需要 64 位
文件校验时，io.Copy + Hash 组合容易漏掉什么？
常见写法是 io.Copy(h, file)，看起来简洁，但有两个隐形坑：
- 没检查
io.Copy返回的 error —— 文件读取中途失败（如权限变化、磁盘满），h.Sum64()仍返回部分结果，你以为算完了 -
file的 offset 没重置（比如之前读过几字节），io.Copy从当前 offset 开始，不是从头
安全做法是显式控制读取，并校验错误：
f, _ := os.Open("data.bin")
defer f.Close()
h := crc32.New(crc32.IEEE)
if _, err := io.Copy(h, f); err != nil {
log.Fatal(err) // 别忽略
}
sum := h.Sum32()
另外，大文件建议用固定 buffer 分块读（bufio.Reader 或手动 make([]byte, 32），避免 <code>io.Copy 内部分配临时 buffer 带来 GC 压力。
CRC 值怎么跟其他语言/设备对齐？关键就三件事
跨系统校验失败，90% 出在这三点，不是算法问题：
- 初始值（init value）：Go 默认是 0，但有些硬件 CRC 引擎用
0xffffffff；这时得自己 xor 结果，或改用自定义Table - 输入是否反转（reflect in）：Go 的
crc32.IEEE默认不反转字节内比特顺序；若对方协议要求反转（如某些 Modbus 变种），需预处理数据 - 输出是否反转 + xor（reflect out / xor out）：比如 PNG 要求最终结果再 xor
0xffffffff，Go 不自动做，得手动sum ^ 0xffffffff
别猜，查协议原文或对方示例代码里那行 “final crc ^= 0xffffffff” —— 对齐点永远在这些细节里，不在算法名上。
