Go hash/crc64.Checksum 怎样用指定 Table 计算整段数据

我在给文件摘要做协议对接时，最容易写错的不是 crc64.Checksum 这一行，而是把对方约定的多项式和输出格式弄混。这个函数的正确调用关系很固定：先用多项式得到 *crc64.Table，再把完整的 []byte 和 Table 一起传给 Checksum，最后按协议展示返回的 uint64。

官方地址：https://pkg.go.dev/hash/crc64#Checksum

如果当前数据已经完整放在内存里，直接使用 crc64.Checksum(data, crc64.MakeTable(crc64.ECMA)) 即可。真正需要先确认的是对端使用 ISO 还是 ECMA；两者得到的 Table 和校验结果不能混用。

先把输入、Table 和输出分清

hash/crc64 实现的是 64 位循环冗余校验。Checksum 有两个参数：待计算的字节切片，以及由多项式代表的 *crc64.Table。它返回一个 uint64，不是字符串，也不是已经排好序的字节数组。

可以先记住下面这组对应关系：

• crc64.ISO：ISO 3309 中定义的多项式，常见于 HDLC 语境。
• crc64.ECMA：ECMA 182 中定义的多项式。
• crc64.MakeTable(poly)：根据多项式生成高效处理用的 256 项 Table。
• crc64.Checksum(data, tab)：对整段 data 计算校验值。

这里的 Table 不是“结果缓存”。它决定了计算采用哪套多项式；同一段数据换一个 Table，结果变化是正常现象。

先选对 Table：ISO 与 ECMA 不是同一个结果

如果协议、文件格式或已有系统已经写明 CRC-64 的变体，就按协议选择，不要因为 ECMA 这个名字更常见就直接替换。两套 Table 的关系可以看成“不同规则生成的两本查表”，后续的 Checksum 只是忠实地使用你传入的那一本。

工程上建议把 Table 的选择集中在一个变量或配置映射里，避免调用点散落着不同的 MakeTable。这样阅读代码时，可以很快看出当前校验值遵循的是哪套协议规则。

package main

import (
	"fmt"
	"hash/crc64"
)

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

	// Table 由协议约定的多项式生成；ISO 和 ECMA 不能混着比较。
	tab := crc64.MakeTable(crc64.ECMA)

	// Checksum 直接处理完整字节切片，返回 64 位无符号校验值。
	sum := crc64.Checksum(data, tab)

	// %016X 固定输出 16 个十六进制字符，便于日志和协议字段对齐。
	fmt.Printf("CRC64=%016X\\n", sum)
}

示例把 Table 单独保存，是为了突出它的职责：data 是本次要计算的内容，tab 是计算规则。Table 生成后不要修改其内容；官方文档明确说明，MakeTable 返回的 Table 内容不可修改。

Checksum 的输入、Table 与输出关系

当数据已经是完整的 []byte 时，Checksum 是最短的表达。它不会替你把文本编码成 UTF-8，也不会替你处理协议头、换行或大小写；这些都属于传入字节或展示层的责任。

因此排查“双方校验值不一致”时，可以按三个问题拆开：

1. 双方输入的字节是否完全相同，例如是否一方多了换行或 BOM。
2. 双方是否使用同一个 CRC64 多项式，生成了同一种 Table。
3. 双方比较的是原始数值，还是固定宽度十六进制、大端字节等展示结果。

第三点尤其容易被忽略。%016X 只是把 uint64 以 16 位十六进制显示；如果要写入二进制协议，则应按照协议规定的字节序编码，不能把日志字符串直接当成 8 字节结果。

复用 Table，但不要把整段计算误当成流式计算

同一套 CRC64 规则会被反复使用时，Table 可以创建一次并复用。这样既能让代码明确表达协议，也避免在每次调用处重复构造查表对象。复用的是规则对象，不是上一次的校验状态；每次调用 Checksum 都从这一次传入的完整数据重新计算。

package main

import (
	"fmt"
	"hash/crc64"
)

func checksumText(tab *crc64.Table, text string) uint64 {
	// 只有完整文本需要一次性校验时，转换成 []byte 后直接计算。
	return crc64.Checksum([]byte(text), tab)
}

func main() {
	// 程序生命周期内固定使用同一套协议规则，并在多次调用间复用。
	tab := crc64.MakeTable(crc64.ISO)

	left := checksumText(tab, "header")
	right := checksumText(tab, "payload")
	fmt.Printf("header=%016X payload=%016X\\n", left, right)
}

这篇文章的范围是完整数据的 Checksum。如果输入来自大文件、网络流或持续到达的分片，就不应为了套用这个短调用而先把全部内容拼到内存中；那是 Update 或 hash.Hash64 的另一类设计问题，应该单独决定状态、分片顺序和资源生命周期。

最后用一张表固定团队口径

记忆这条主线就够了：协议决定多项式，多项式生成 Table，Table 与完整字节共同决定 uint64，展示格式再由交换协议决定。

相关问题

ISO 和 ECMA 哪个更准确？

没有脱离协议的“更准确”。它们是不同的预定义多项式，必须和数据生产方的约定保持一致。

为什么同样的字符串每次结果应该相同？

只要输入字节、Table 和计算方式都没有变化，整段 Checksum 的返回值就应保持一致。先检查换行、编码和 Table，而不是先改输出格式。

为什么十六进制结果前面要补零？

CRC64 的数值可能以较短的十六进制形式显示。使用 %016X 可以固定成 16 个字符，便于日志对齐和字符串比较，但它不改变原始 uint64。