Go hash/crc32.MakeTable 怎样为自定义 CRC 多项式复用校验表

如果一个服务要反复计算同一种 CRC，却在每次请求里重新调用 crc32.MakeTable，真正被重复创建的是同一份多项式查表配置。更合适的做法是：先用多项式创建一次 *crc32.Table，后续把这张表传给 Checksum 或 New。表可以共享，但每次计算的哈希状态仍应独立。

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

先把 MakeTable 的参数看成一张固定校验表

hash/crc32 把 CRC-32 多项式用 LSB-first，也就是反转表示记录。官方示例使用 CRC32-Q 的反转值 0xD5828281；如果你的协议给的是普通多项式表达式，不能不加转换就把它当成这个参数。

如果只需要最常见的 IEEE CRC-32，可以直接使用 crc32.IEEETable 或 crc32.ChecksumIEEE。只有协议明确规定了其他多项式时，才需要自己调用 MakeTable：

package checksum

import "hash/crc32"

const crc32Q uint32 = 0xD5828281 // CRC32-Q 的反转表示，必须和协议约定一致。

var crc32QTable = crc32.MakeTable(crc32Q) // 创建一次，后续计算只读取这张表。

Table 是按多项式构造的 256 项查表结构，官方文档明确要求不要修改其内容。把它视为只读配置，能让“算法选择”和“本次数据状态”保持分离。

重复计算时复用表，不复用哈希状态

对一整块数据，Checksum 最直接；对文件分片或流式输入，使用 New(table) 创建本次计算的 hash.Hash32。下面的函数让每一份输入都有自己的状态，同时共用同一张表：

package checksum

import (
    "hash/crc32"
)

func sumBlock(data []byte) uint32 {
    // Table 只描述算法；Checksum 不会修改它，适合被重复调用。
    return crc32.Checksum(data, crc32QTable)
}

func sumParts(parts [][]byte) (uint32, error) {
    // 每次调用都创建独立状态，避免把上一份数据的进度带进来。
    h := crc32.New(crc32QTable)
    for _, part := range parts {
        // hash.Hash 的 Write 在 crc32 实现中不会返回写入错误，但仍保留接口判断。
        if _, err := h.Write(part); err != nil {
            return 0, err
        }
    }
    return h.Sum32(), nil
}

同一组分片按相同顺序写入时，流式写法表达的是“连续输入”。如果把分片顺序换掉，校验值通常也会变；这不是表复用失效，而是输入字节序列已经不同。

需要增量计算时，用 Update 延续同一份状态

如果业务本来就维护一个 uint32 的增量校验值，可以把同一张表传给 Update。这里的状态是调用方持有的数值，不是共享的 Table：

func updateParts(parts [][]byte) uint32 {
    var crc uint32 // 初始值和协议约定保持一致；不要随意套用别的实现的初始值。
    for _, part := range parts {
        // Update 只把当前分片并入已有 CRC，表仍然只是只读算法配置。
        crc = crc32.Update(crc, crc32QTable, part)
    }
    return crc
}

选择 Checksum、New 还是 Update，取决于调用边界：单块数据用 Checksum，需要实现 io.Writer 语义或分片写入用 New，已经有增量数值状态时才用 Update。三者都必须使用同一套多项式、初始值、最终异或和字节序约定，不能只记录一个“CRC32”名称。

四个容易让结果对不上的边界

最后，若这是文件格式或跨语言协议的一部分，建议把多项式的表示方式、初始 CRC、是否逐字节反射、最终异或值以及输出字节序一起写入协议文档。只保存 0xD5828281 而不解释它是反转表示，后续实现很容易出现“代码看着一样、结果却不同”的问题。

相关问题

MakeTable 每次调用都会改变全局状态吗？

它返回一张由多项式构造的表；把返回值当作只读配置即可。真正需要隔离的是每次计算的哈希状态。

只计算 IEEE CRC-32 还要 MakeTable 吗？

通常不需要，直接使用 ChecksumIEEE 或官方提供的 IEEETable 更清楚。

CRC 能不能替代 SHA-256？

不能。CRC 适合检测意外损坏或传输错误；涉及对抗篡改、签名或认证时，应使用密码学方案。