hash/crc32 如何选择 IEEE 与 Castagnoli 校验表

在 Go 的 hash/crc32 里，IEEE 和 Castagnoli 不是两个可以随意互换的“速度档位”，而是两种不同的 CRC-32 多项式。选择时先看数据是否要兼容外部格式：gzip、zip、PNG 等常见格式使用 IEEE；如果是双方都由自己控制的内部数据完整性检查，可以考虑 Castagnoli。协议已经写明多项式时，协议要求优先于个人偏好。

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

最稳妥的规则是：外部协议或文件格式规定了 IEEE，就使用 IEEE；内部协议没有历史兼容包袱、主要关注错误检测能力时，再选择 Castagnoli。无论选哪一种，通信两端、写入端和读取端都必须使用同一张表。

• IEEE：兼容性优先，适合已经规定 CRC-32/IEEE 的文件格式、协议或跨语言接口。
• Castagnoli：内部系统可以统一控制时，用于更关注错误检测特性的场景。
• 调用方式：一次性字节切片用 crc32.Checksum，分段输入用 crc32.New。
• 安全边界：CRC-32 用于发现意外错误，不等于密码学哈希，也不能替代 MAC 或数字签名。

先判断协议是否已经固定多项式

第一步不是看哪张表名字更熟，而是找数据格式或协议的定义。如果文件格式、设备协议、已有 SDK 或跨语言实现已经规定 CRC-32/IEEE，那么 Go 代码必须跟着规定走。Go 官方文档把 IEEE 描述为最常见的 CRC-32 多项式，并列举了 Ethernet、v.42、FDDI、gzip、zip、PNG 等使用场景；Castagnoli 则用于 iSCSI，并具有更好的错误检测特性。

这类场景中，校验值的意义来自“双方算出同一个结果”。即使另一张表在某个基准中更快，只要它与协议规定不同，得到的就是另一个 CRC-32 结果，不能通过改字段名或转换字节序来补救。

IEEE 和 Castagnoli 分别适合什么任务

可以把两种表的使用边界拆成两个问题。

需要兼容已有格式时选 IEEE

当你的程序要读写 gzip、zip、PNG，或者要和已经约定 CRC-32/IEEE 的设备、服务交互时，选 IEEE。代码可以直接使用标准库提供的 crc32.IEEETable，也可以通过 crc32.MakeTable(crc32.IEEE) 获取对应表。两者表达的是同一个多项式，不要在项目里分别保存一套含义不明的自定义常量。

内部链路更关注错误检测时选 Castagnoli

如果数据只在自己的服务、队列或存储格式中流转，且写入方与读取方都能同步升级，可以考虑 Castagnoli。它的优势是错误检测特性，而不是“可以防攻击”。例如内部块校验、分片传输的意外损坏检测，可以把 Castagnoli 作为明确的协议约定。

这里有一个容易忽略的条件：选择 Castagnoli 后，要把多项式记录在协议说明、字段注释或版本契约中。否则后来接入的程序很可能默认 IEEE，最终表现为“数据没有变，但校验总是不相等”。

用 Checksum 写一次性校验

对已经放在内存里的完整字节切片，crc32.Checksum 是最短的写法。下面的例子把表作为参数传入，避免调用处看不出使用的是哪一种多项式。

package main

import (
    "fmt"
    "hash/crc32"
)

func checksum(data []byte, table *crc32.Table) uint32 {
    // 表由调用方明确选择，避免 IEEE 和 Castagnoli 被混用。
    return crc32.Checksum(data, table)
}

func main() {
    data := []byte("order-2026-11-11")

    // 需要兼容常见外部格式时使用 IEEE 表。
    ieee := checksum(data, crc32.IEEETable)

    // 内部协议选择 Castagnoli 时，写入端和读取端都要固定这张表。
    castagnoliTable := crc32.MakeTable(crc32.Castagnoli)
    castagnoli := checksum(data, castagnoliTable)

    fmt.Printf("IEEE=%08x Castagnoli=%08x\n", ieee, castagnoli)
}

同一段输入用两张表得到不同结果是正常现象，不代表其中一张“算错了”。真正需要核对的是：协议双方是否使用同一个多项式、输入字节是否完全一致，以及是否在校验前做了相同的编码和字段拼接。

分段读取时用 New 保持同一张表

文件、网络响应或大消息通常不会一次性装入内存，这时可以把表交给 crc32.New，再通过 io.Writer 接口持续写入数据。下面的示例模拟两段输入，适合迁移到文件读取循环或网络读取循环中。

func streamingChecksum(chunks ...[]byte) (uint32, error) {
    // 创建一次表和 Hash32，后续所有分片共享同一个累积状态。
    h := crc32.New(crc32.MakeTable(crc32.Castagnoli))
    for _, chunk := range chunks {
        if _, err := h.Write(chunk); err != nil {
            // 任一分片写入失败都不返回不完整的校验值。
            return 0, err
        }
    }
    return h.Sum32(), nil
}

用可复现基准比较，而不是凭感觉猜速度

如果业务没有外部协议约束，仍然想比较两种表在当前机器上的表现，应固定输入长度、数据内容、调用方式和 Go 版本。不要把“IEEE 更常见”或“Castagnoli 更适合内部数据”误读成无条件的性能结论。CRC-32 的实际吞吐还可能受到硬件指令、输入长度和是否重复创建表的影响。

func BenchmarkCRC32Tables(b *testing.B) {
    payload := bytes.Repeat([]byte("g"), 1

运行 go test -bench=CRC32Tables -benchmem 后，重点看每秒处理字节数和分配次数。性能数据只回答“这台机器、这组输入下怎样”，不能推翻协议兼容性要求；若协议已经固定 IEEE，就应先保证互操作，再决定是否优化其他环节。

一张表做完最后的选择

常见问题

IEEE 和 Castagnoli 算出的值为什么不同？

因为它们代表不同的 CRC-32 多项式。只要输入相同但表不同，结果不同就是预期行为；核对时先确认两端是否使用同一张表。

Castagnoli 能替代密码学哈希吗？

不能。CRC-32 主要用于发现传输、存储或处理中的偶然错误，不提供密码学意义上的抗碰撞和认证能力。需要防篡改时，应按威胁模型选择 MAC、数字签名或密码学哈希组合。

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

不需要。表可以复用，尤其是在循环或高频路径中应把表创建放在外层。对于 IEEE 可以直接复用 crc32.IEEETable；对于 Castagnoli 可以在初始化阶段创建并保存表。

流式计算和一次性计算会得到不同值吗？

只要字节顺序、表和写入范围完全一致，分段写入同一张表的 Hash32 应与一次性计算对应同一数据得到相同校验值。出现差异时，优先检查是否漏写、重复写入或把不同编码后的字节拿来比较。

最终可以把选择压缩成一句话：先服从协议，再看内部数据的错误检测需求，最后用同一张明确的表贯穿写入、读取和基准测试。这样 IEEE 与 Castagnoli 就不再是凭经验争论的两个名字，而是可以被记录、复现和维护的工程决策。