Go crc64.Update 怎样延续分块数据的校验值

如果数据不是一次性到达，而是从文件、网络或消息流中分成多个 []byte 分块读取，可以用 hash/crc64.Update 延续同一个 CRC64 校验值。核心写法是：先用同一个多项式创建 *crc64.Table，从初始校验值开始处理第一块，再把每次 Update 的返回值传给下一次调用。不要在每个分块上重新从零计算，也不要中途换一张 Table。

官方文档：https://pkg.go.dev/hash/crc64#Update

crc64.Update 的返回值就是“加入当前字节块之后”的新 CRC。只要字节顺序、Table 和初始值一致，连续分块更新可以表达同一份数据的整体校验过程。

先看清 crc64.Update 的三个参数

函数签名是 func Update(crc uint64, tab *Table, p []byte) uint64。第一个参数是目前已经累积到的 CRC 值，第二个参数是由多项式构造的处理表，第三个参数是本次要加入的字节。它返回一个新的 uint64，调用方要把这个返回值保存下来。

crc64.MakeTable 可以根据 crc64.ISO 或 crc64.ECMA 等预定义多项式创建 Table。官方文档把 Table 描述为用于高效处理的 256 项表，并明确提示返回表的内容不能修改；工程代码通常在初始化阶段创建一次，然后在后续分块计算中复用。

把多个数据块按原顺序连续更新

分块场景的状态只有一个：当前 CRC。每读到一块数据，就用当前 CRC、同一个 Table 和这块字节调用一次 Update，然后用返回值覆盖旧状态。下面的示例用三个内存分块模拟流式输入，重点是状态传递方式。

package main

import (
	"fmt"
	"hash/crc64"
)

func main() {
	// 同一张 Table 要贯穿整次分块计算，不能每块重新创建或切换多项式。
	tab := crc64.MakeTable(crc64.ECMA)
	var crc uint64
	chunks := [][]byte{
		[]byte("header-"),
		[]byte("body-"),
		[]byte("tail"),
	}

	for _, chunk := range chunks {
		// Update 返回加入当前分块后的状态，必须交给下一轮。
		crc = crc64.Update(crc, tab, chunk)
	}

	fmt.Printf("分块计算完成：%016x\n", crc)
}

这里的 var crc uint64 表示从零值开始一段新的计算。若上层协议已经规定了某个初始 CRC，就应该把协议要求的值作为第一参数传入，而不是擅自归零。相同输入在不同初始值或不同多项式下得到的校验值不能直接比较。

用 Checksum 对照整块计算

排查分块逻辑时，可以把同样的字节按原顺序拼接，再交给 crc64.Checksum。对同一个 Table 和同一个初始约定而言，连续 Update 的结果应与整块计算所表达的 CRC 规则一致。这个对照关系适合检查是否漏了某块、交换了顺序，或在循环内部错误地把 CRC 重置为零。

package main

import (
	"bytes"
	"fmt"
	"hash/crc64"
)

func main() {
	// 这里复用同一个 Table，避免把多项式差异误判成分块逻辑差异。
	tab := crc64.MakeTable(crc64.ECMA)
	chunks := [][]byte{[]byte("header-"), []byte("body-"), []byte("tail")}

	var incremental uint64
	for _, chunk := range chunks {
		// 每一轮都把上一轮的返回值作为下一轮的起点。
		incremental = crc64.Update(incremental, tab, chunk)
	}

	whole := bytes.Join(chunks, nil)
	// Checksum 直接处理拼接后的全部字节，用来做整体结果对照。
	checksum := crc64.Checksum(whole, tab)
	fmt.Println("分块结果：", incremental)
	fmt.Println("整块结果：", checksum)
}

如果对照结果不同，优先检查三件事：分块是否仍按原始顺序传入；是否有分块被跳过或重复；是否把 crc 在循环中重新声明成局部变量。还要注意，Checksum 本身从初始状态计算整块数据，它不是把任意中间状态“合并”进另一个 CRC 的通用接口。

处理空块、空输入和 Table 生命周期

读取器偶尔会产生长度为零的分块。把空块交给 Update 不会增加实际字节，调用方可以直接处理，也可以在读取循环里跳过；关键是不要因为空块而重置 CRC。真正的空输入可以保留零值结果，还是使用业务协议规定的初始值，应由协议语义决定。

Table 则应该视为只读配置：创建后在多个分块之间共享，避免在高频循环里反复调用 MakeTable。如果多个任务并发计算同一份数据，可以共享只读 Table，但每份数据都必须维护自己的 CRC 状态，不能让不同输入共用同一个可变的 uint64 变量。

package checksum

import "hash/crc64"

// UpdateChunks 按输入顺序计算分块 CRC64，并复用调用方提供的 Table。
func UpdateChunks(tab *crc64.Table, chunks [][]byte) uint64 {
	var crc uint64
	for _, chunk := range chunks {
		// 空块不会产生新字节；保留调用也能让循环语义保持简单。
		crc = crc64.Update(crc, tab, chunk)
	}
	return crc
}

这个封装把两个容易出错的边界固定下来：状态只在函数内部按顺序推进，Table 由外部创建并复用。它仍然不负责分块排序、网络重试去重或密码学安全；如果同一分块可能被重复投递，应先在更上层解决消息幂等问题。

常见问题

每个分块都调用 crc64.Checksum 可以吗？

可以分别得到每块的 CRC，但这些值不是整份数据的连续 CRC。需要表达整段数据时，应把上一次 Update 的返回值传给下一次。

为什么不能在每次循环里把 crc 写成零值？

因为那会让每个分块都从同一个初始状态开始，得到的是若干独立校验，而不是按原字节序列累积出的一个状态。

crc64.Update 能防止数据被恶意篡改吗？

CRC64 主要用于发现传输或存储中的偶然差错，不提供密码学认证。需要对抗主动篡改时，应根据协议采用合适的认证机制，不能把 CRC 当作安全签名。

总结：用 crc64.MakeTable 创建并复用同一张 Table，从约定的初始值开始，把每个分块依次交给 crc64.Update 并接住返回值；排查问题时再用同一 Table 对拼接后的数据调用 crc64.Checksum 做整体对照。