Go crc64.Update 分段计算为什么要沿用上一次的 CRC 值

在分片上传、网络帧或流式文件校验中，crc64.Update 的第一个参数不是“本次计算的初始配置”，而是已经处理过的 CRC 状态。正确写法是：第一段从 0 开始，后续每一段都接住上一次返回值，并且始终使用同一张 crc64.Table。

如果每段都调用 crc64.Update(0, table, chunk)，得到的是多个独立片段的校验值；它们不能直接代表整段拼接数据的 CRC。Go 官方文档把 Update 定义为“把 p 中的字节添加到 crc”，这个语义正是分段计算要沿用上一次结果的原因。

crc64.Update 的第一个参数到底代表什么

可以把一次计算看成一个持续变化的状态：

• 已有 CRC：前面字节已经产生的中间结果；第一段通常使用 0。
• 当前分片：这次要追加处理的字节。
• Table：决定 CRC 多项式的表，所有分片必须保持一致。
• 返回值：处理完当前分片后的新状态，交给下一次 Update。

因此，Update 更像“继续处理”，不是“重新计算”。这里的状态传递只描述函数输入输出关系，不涉及把同一张表在多个 goroutine 中共享的并发设计。

整块 Checksum 和分段 Update 为什么能得到同一个结果

在输入顺序不变、分片之间没有丢字节或重复字节、并且使用同一张表的前提下，整块计算和连续分段计算的边界可以这样对应：

package main

import (
    "fmt"
    "hash/crc64"
)

func main() {
    table := crc64.MakeTable(crc64.ECMA)
    first := []byte("header:")
    second := []byte("payload")

    // 整块路径：把两段按原顺序拼接后一次计算。
    whole := crc64.Checksum(append(append([]byte{}, first...), second...), table)

    // 分片路径：第一段从零开始，第二段沿用上一段的返回值。
    partial := crc64.Update(0, table, first)
    partial = crc64.Update(partial, table, second)

    // 两条路径处理的是同一串字节，最终 CRC 应保持一致。
    fmt.Println(whole == partial)
}

这里的关键不是“分成两次调用”本身，而是第二次调用拿到了第一次的状态。若把 partial 再次改成 0，第二次就脱离了前半段输入，结果自然只对应 second 这一段。

标准库的 Checksum 可以理解为从零状态开始处理完整输入；而 hash.Hash64 的 Write 也会把新字节追加到内部 CRC 状态。两者表达的是同一种累计模型。

把 Update 放进分片循环时要保留哪几个条件

真实项目通常不会只处理两个切片，可以把循环写成下面的形式：

package main

import "hash/crc64"

func checksumChunks(chunks [][]byte, table *crc64.Table) uint64 {
    var crc uint64
    for _, chunk := range chunks {
        // 空分片不会改变状态，但仍按统一路径处理，避免特殊分支漏掉边界。
        crc = crc64.Update(crc, table, chunk)
    }
    return crc
}

循环里最容易被忽略的是三点：不能在每轮把 crc 重新声明为零；不能把分片重新排序；不能在中途更换由另一个多项式创建的表。空切片可以经过 Update，它不增加输入字节，也不会凭空产生新的数据。

如果上层协议把 CRC 作为每个独立帧的字段，那么每个帧确实可以从零开始；但那是“每帧独立校验”的协议定义，和“多个分片共同代表一份完整数据”的需求不是一回事。

结果不一致时先看这四个地方

1. 是否每段都从零开始。 搜索循环内是否反复出现 crc64.Update(0, table, chunk)。
2. 是否漏片或重复片。 把分片长度和顺序与原始输入的拼接边界逐一对照。
3. 是否更换了 Table。 ECMA 与 ISO 是不同多项式，不能拿来互相对照。
4. 是否比较了同一种结果。 一边比较整份数据，另一边却只比较最后一个 chunk，结论一定不一致。

排查时可以暂时同时保留“整块路径”和“分片路径”，只比较二者的最终 uint64 值。先确认输入边界一致，再检查状态是否传递，比直接怀疑 CRC 算法更快。

常见问题

为什么第一段通常传 0？

因为它代表从空输入开始累计。若协议规定了其他初始状态，应明确记录该状态，并让整块与分段两条路径使用同一个起点。

能不能把每段 CRC 再相加？

不能用普通加法拼出整块 CRC。分段结果必须通过 Update 的状态输入继续处理，不能把多个独立结果当作可相加的片段摘要。

小结：crc64.Update 的第一个参数就是累计状态。第一段从约定的初始值开始，后续沿用上一次返回值，所有输入按原顺序经过同一张表，才能让分段结果与整块校验保持一致。