Go crc32 MakeTable 怎样选择 IEEE 与 Castagnoli

如果一个 Go 程序要和已有文件格式、网络协议或其他语言实现互相校验，crc32.MakeTable 的参数不能凭感觉选择。IEEE 和 Castagnoli 都是合法的 CRC-32 多项式，但它们对同一组字节会得到不同结果；真正的选型依据是兼容对象的约定。传统 CRC-32 兼容场景优先使用 crc32.IEEE，明确要求 CRC32C 的场景才使用 crc32.Castagnoli。

本文把一次性计算、流式计算和结果表达放在同一条线上，示例只围绕标准库 hash/crc32 展开。配图是静态结构说明图，不是程序运行截图，也不代表本机已经执行了示例。

先按兼容对象选择多项式

crc32.IEEE 是 Go 文档中标注为最常见的 CRC-32 多项式，常见于 Ethernet、gzip、zip、PNG 等传统 CRC-32 兼容对象。crc32.Castagnoli 是 CRC32C 使用的多项式，适合对端明确写着 CRC32C、Castagnoli 或给出对应校验表的协议。

不要因为 Castagnoli 的错误检测特性描述更好，就把一个原本约定 IEEE 的文件格式改成 Castagnoli。校验算法的第一目标是双方得到同一个结果；算法特性只能在协议允许选择时作为第二层决策。

用 MakeTable 把选择写进代码

MakeTable 接收多项式并返回一张校验表。把选型写成一个有名字的变量，能让代码审查者直接看出它要兼容哪一类数据；不要在多个调用点散落裸的十六进制常量。

package main

import (
    "fmt"
    "hash/crc32"
)

func main() {
    data := []byte("record-001")

    // 传统 CRC-32 兼容对象使用 IEEE；CRC32C 对端才选择 Castagnoli。
    ieeeTable := crc32.MakeTable(crc32.IEEE)
    castagnoliTable := crc32.MakeTable(crc32.Castagnoli)

    // Checksum 直接返回 uint32，适合已经完整放在内存中的字节切片。
    ieee := crc32.Checksum(data, ieeeTable)
    castagnoli := crc32.Checksum(data, castagnoliTable)

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

这两个值都可能看起来“正确”，但它们回答的是不同算法的问题。验收时应拿同一份输入字节、同一个多项式和对端规定的输出格式比较，而不是只比较“函数调用成功”。

一次性数据用 Checksum，分片数据用 New 和 Update

小对象或已经完整读入内存的数据可以直接调用 Checksum(data, table)。文件、上传流或消息分片不必先拼成一块大切片，可以创建 hash.Hash32，持续写入分片，再读取结果。

package main

import (
    "encoding/binary"
    "fmt"
    "hash/crc32"
)

func main() {
    table := crc32.MakeTable(crc32.Castagnoli)
    h := crc32.New(table)

    chunks := [][]byte{
        []byte("header|"),
        []byte("payload"),
    }
    for _, chunk := range chunks {
        // 每个分片都写入同一个状态，顺序就是校验输入顺序。
        if _, err := h.Write(chunk); err != nil {
            // hash.Hash32 的 Write 当前不会返回写入错误，但保留判断便于替换为有错误的 Reader。
            panic(err)
        }
    }

    // Sum32 返回数值；Sum(nil) 返回大端序的四字节表示。
    value := h.Sum32()
    encoded := h.Sum(nil)
    var fromBytes uint32
    if len(encoded) == crc32.Size {
        fromBytes = binary.BigEndian.Uint32(encoded)
    }
    fmt.Printf("value=%08x encoded=%08x\\n", value, fromBytes)
}

New 绑定的是你传入的 *crc32.Table，所以表一旦选错，后面的分片写入再完整也无法得到对端期待的结果。Hash32.Sum 会把当前值按大端字节序追加到参数切片；需要网络字段或文件字段时，要同时确认对端是否要求这种字节序。

已有 CRC 状态时用 Update

如果上层已经维护了一个 uint32 状态，或者数据被分成多个阶段处理，可以使用 Update。它接收当前 CRC、同一张表和新的字节片段，返回加入片段后的状态。

package main

import (
    "fmt"
    "hash/crc32"
)

func main() {
    table := crc32.MakeTable(crc32.IEEE)
    crc := uint32(0)

    for _, part := range [][]byte{[]byte("part-a"), []byte("part-b")} {
        // Update 复用上一阶段的数值，table 必须与首次计算保持一致。
        crc = crc32.Update(crc, table, part)
    }

    fmt.Printf("crc=%08x\\n", crc)
}

这里的“状态”不是可以跨算法复用的通用数字。IEEE 状态只能继续交给 IEEE 表，Castagnoli 状态只能继续交给 Castagnoli 表；中途更换表会让结果失去协议意义。

比较结果时要同时看数值、字节序和重置边界

同一个 hash.Hash32 需要重新处理另一条独立消息时，应先调用 Reset，而不是继续读取旧状态。crc32.Table 是查表对象，官方文档要求其内容不要修改；共享一张只读表可以避免重复构造，但不要把它当作可写缓存。

不要把 CRC32 当成密码学摘要

CRC32 的定位是检测传输或存储中的常见数据错误，以及让双方快速判断内容是否发生变化。它不是密码学哈希，不能用于密码存储、签名、抗攻击完整性证明或令牌防伪。若需求是抵抗主动篡改或需要密码学摘要，应改用项目明确要求的密码学方案，并单独确认协议格式。

同理，Castagnoli 的错误检测特性更好，也不等于它具备密码学安全性。它解决的是 CRC 多项式和错误检测能力的选择问题，不改变 CRC32 的安全边界。

发布前用一张清单验收兼容性

1. 确认对端写的是 CRC-32、IEEE、CRC32C 还是 Castagnoli，不要只看“CRC32”三个字。
2. 确认参与计算的是原始字节，不是经过字符集转换、JSON 重排或额外换行后的文本。
3. 确认使用 Checksum、New 或 Update 时采用同一张 Table。
4. 确认输出是十进制数、十六进制字符串、四字节大端字段，还是协议规定的其他表示。
5. 确认 CRC32 只是错误检测，不把它当作密码学完整性或身份认证手段。

一句话总结：先由兼容对象决定多项式，再用 MakeTable 固定这个决定；完整数据调用 Checksum，分片数据使用 New 或 Update，最后把结果数值、字节序和安全用途一起对齐。

相关问题

IEEE 和 Castagnoli 能不能互换？

不能直接互换。同一输入使用不同多项式会得到不同 CRC；只有协议或对端实现明确允许切换时，才应把它作为选项。

为什么 Checksum 和 Hash32.Sum 的结果看起来不一样？

Checksum 返回 uint32 数值，Sum 返回按大端序追加的四个字节。将字节转换回大端 uint32 后再比较，避免把表示差异误判为算法差异。

CRC32 能用来保存密码吗？

不能。CRC32 包括 Castagnoli 都不是密码学摘要，不能承担密码存储、签名或主动篡改防护。