Go hash/crc32 怎样选择校验表

Go 的 hash/crc32 不是“随便挑一个表都能算”的接口：同一段字节换了多项式，结果就不再兼容。实际选择顺序应是先看文件格式或通信协议，再看是否需要 CRC32C，最后决定用一次性校验还是流式更新。

官方文档：https://pkg.go.dev/hash/crc32

先按协议选多项式，不要按函数名猜表

crc32.Table 是根据多项式构造的 256 项查找表。Go 预置了三个常量：IEEE、Castagnoli 和 Koopman。官方文档说明 IEEE 是最常见的 CRC-32 多项式，常见于 Ethernet、gzip、ZIP、PNG；Castagnoli 用于 iSCSI，并具有比 IEEE 更好的错误检测特性；Koopman 也有类似的检测特性说明。

这并不意味着 Castagnoli 在所有项目里都“更正确”。如果对端写入的是 IEEE，改成 Castagnoli 只会得到另一套校验值，数据即使没有损坏也会被判定为不匹配。协议只写“CRC-32”时还要继续查格式说明，不能把 CRC32C 直接当成默认值。

一次性数据与流式数据使用同一张表

短消息可以直接调用 Checksum；明确是 IEEE 时，ChecksumIEEE 更直观。长文件、网络帧或分段读取则应先创建表，再把每个分块交给 Update。下面的例子同时演示了表复用和分块结果与一次性结果的一致性。

package main

import (
    "bytes"
    "fmt"
    "hash/crc32"
)

func main() {
    data := []byte("order-2026-11-02")
    table := crc32.MakeTable(crc32.Castagnoli) // CRC32C 场景固定使用 Castagnoli 表

    whole := crc32.Checksum(data, table) // 一次性计算，适合已经在内存中的数据
    part := uint32(0)
    for _, chunk := range [][]byte{data[:6], data[6:]} {
        part = crc32.Update(part, table, chunk) // 分块必须沿用同一张表和上一次结果
    }

    fmt.Printf("whole=%08x split=%08x same=%v\n", whole, part, whole == part)
    _ = bytes.NewBuffer(data) // 实际项目可把 Reader 的缓冲块逐次传给 Update
}

这里的 part 初值为零，后续每次接收上一轮结果。不要在循环内重新创建表，也不要把第二块重新从零开始计算后再简单拼接。若使用 hash.Hash32 的写入模型，则用 crc32.New(table) 创建对象；它的 Sum 按大端字节序追加结果。

自定义多项式只在规范给出时使用

协议如果给出了 CRC32-Q 等非预置多项式，才能调用 MakeTable。Go 文档特别强调多项式使用反射后的 LSB-first 表示法，不能直接把资料里的正向二进制多项式原样填进去。自定义表还要固定初始化位置，并把表视为只读：官方 API 明确要求不要修改 Table 内容。

发布前用四项清单排除选表错误

1. 确认对端的多项式名称、反射表示、初始值和最终异或规则，而不是只看“CRC-32”四个字。
2. 准备一个固定字节样例，记录预期十六进制结果；跨语言联调时同时确认输出字节序。
3. 让一次性计算和分块 Update 都跑同一输入，结果不一致通常是初值、分块状态或表选错。
4. 把 CRC 只用于传输或存储错误检测；它不是抗碰撞密码学摘要，也不能单独证明数据来自可信发送者。

常见问题

CRC-32 和 CRC32C 可以互换吗？

不能。CRC32C 通常对应 Castagnoli，多项式不同，除非协议明确允许，否则结果不能互相校验。

每次调用 Checksum 都要重新 MakeTable 吗？

不需要。表与多项式绑定，初始化一次后复用即可；高频路径反复建表只增加开销，也让代码更容易误用不同表。

CRC 能代替 SHA-256 做防篡改吗？

不能。CRC 适合发现偶发传输或存储错误；需要抗恶意碰撞或身份认证时，应使用密码学哈希或带密钥的认证机制。