Go crc64 MakeTable 怎样选择 ISO 与 ECMA 多项式

Go 的 hash/crc64 不是只有一个固定算法：它预置了 crc64.ISO 和 crc64.ECMA 两种多项式。选择规则很简单：如果要兼容已有协议、文件格式或对端实现，优先跟随对方规定的多项式；只有在自有协议中没有既定约束时，才把选择写进协议文档并固定下来。两者不能因为都是 CRC-64 就互换，否则同一段数据会得到不同校验值。

本文围绕 crc64.MakeTable 说明这两个多项式怎样落地，并比较 Checksum、New 与 Update 的使用场景。示例依据 Go 官方 hash/crc64 文档：ISO 多项式定义于 ISO 3309，ECMA 多项式定义于 ECMA 182；MakeTable 返回的表不应被修改。

ISO 与 ECMA 不是可互换的参数

crc64.MakeTable(poly) 的参数决定查表结构代表哪一种 CRC-64 算法。Go 官方包把两个常用选择直接暴露为常量：crc64.ISO 是 0xD800000000000000，crc64.ECMA 是 0xC96C5795D7870F42。因此，真正需要先回答的问题不是“哪个更快”，而是“数据的另一端使用哪个多项式”。

可以把选型写成一张小表：

示例中的变量名刻意体现了“算法配置”这一层。Table 是根据多项式生成的 256 项查表数据，拿到后只用于计算，不要修改它。

package main

import "hash/crc64"

func chooseTable(useECMA bool) *crc64.Table {
	// 对端协议决定多项式；不能把 ISO 和 ECMA 当作可互换的别名。
	poly := crc64.ISO
	if useECMA {
		poly = crc64.ECMA
	}

	// MakeTable 创建与多项式绑定的查表结构，返回后只读使用。
	return crc64.MakeTable(poly)
}

一次性、持续和分块计算怎样选

数据已经完整放在内存中时，crc64.Checksum(data, table) 最直接；数据会持续到达时，用 crc64.New(table) 得到 hash.Hash64，不断写入后再取结果；如果调用方本来就维护一个 uint64 状态，则可以用 crc64.Update 把每个分块接在前一个结果之后。

package main

import (
	"fmt"
	"hash/crc64"
)

func calculate(data, first, second []byte) (uint64, uint64, uint64) {
	// 同一张表保证三条路径使用同一个多项式。
	table := crc64.MakeTable(crc64.ECMA)

	// 完整数据已在内存中时，Checksum 是最小调用路径。
	oneShot := crc64.Checksum(append(append([]byte{}, first...), second...), table)

	// New 返回持续写入的 Hash64；Write 的顺序就是数据顺序。
	h := crc64.New(table)
	_, _ = h.Write(data) // 示例忽略 bytes.Buffer 等内存 Writer 不会产生的常规错误。
	streamed := h.Sum64()

	// Update 接收前一段的 CRC 值，把下一块追加到同一校验上下文。
	crc := crc64.Update(0, table, first)
	crc = crc64.Update(crc, table, second)

	fmt.Println(oneShot, streamed, crc) // 输出仅用于说明三个结果值的角色。
	return oneShot, streamed, crc
}

上面的三条路径只有在输入字节序列和表完全一致时才有可比性。Update 的第一个参数是已有 CRC 状态，不是“分块编号”；分块顺序改变，结果也会改变。实际项目中还要处理写入错误，不能把示例里对 Write 的忽略照搬到网络或文件 Writer。

分块计算时最容易错在哪里

第一，分块计算不能更换表。第一块使用 ECMA、第二块误用 ISO，最终结果没有可解释的兼容意义。第二，不能把每块的 CRC 当成普通数字相加或拼接；应把上一块的状态传给 Update，或者让同一个 Hash64 连续接收所有字节。第三，输入顺序必须保持稳定，协议若规定大端或小端的字段布局，应先按协议编码，再计算字节序列。

hash.Hash64.Sum 返回的摘要会按大端字节序布置；如果协议字段要求特定字节序，写入线上的字节前要在协议层明确转换，不要把“CRC 算法的结果表示”和“业务字段的网络编码”混为一谈。

package main

import "hash/crc64"

func updateChunks(chunks [][]byte) uint64 {
	// 所有分块共享同一张表，表对应的多项式必须写进协议约定。
	table := crc64.MakeTable(crc64.ISO)
	var crc uint64
	for _, chunk := range chunks {
		// 空块不会改变状态；非空块按原始到达顺序继续更新。
		crc = crc64.Update(crc, table, chunk)
	}
	return crc
}

CRC-64 能解决什么，不能解决什么

CRC-64 适合发现传输、存储或拼接过程中的偶发比特错误，前提是两端使用同一多项式、初始状态和结果编码约定。它不是密码学哈希，也不能证明数据来自可信发送者；需要抗篡改或身份认证时，应使用协议要求的认证机制或密码学摘要，不能只把 CRC-64 换成“更大的数字”来代替。

落地前可以保留三条决策：

• 已有规范先于个人偏好：先查清对端是 ISO 还是 ECMA。
• 完整数据用 Checksum，连续输入用 New，手里已有累计状态时用 Update。
• 把多项式、初始状态、分块顺序和结果字节序一起写进协议，不要只记录“使用 CRC-64”。

常见问题

ISO 和 ECMA 哪个更推荐？

没有脱离协议的统一推荐。兼容现有数据时使用现有规范指定的多项式；自有协议则选择一种并固定文档、测试向量和结果编码。

可以先对每个分块调用 Checksum，再合并结果吗？

不能把分块 CRC 当作普通整数直接合并。应使用同一张表连续写入，或把上一块的 CRC 传给 Update。

crc64 能代替 SHA-256 做安全校验吗？

不能。CRC-64 主要用于检测偶发错误，不提供密码学意义上的抗碰撞和身份认证能力。