Go crc64.New 怎么边读取大文件边计算校验和

Go 里计算大文件 CRC64，不需要先调用 io.ReadAll 把全部内容放进内存。更稳妥的做法是用 crc64.New 创建一个可持续写入的 hash.Hash64，再把打开的文件通过 io.CopyBuffer 按固定大小的块送进去，最后用 Sum64 取得累计结果。

先把三个 API 的职责分开

hash/crc64 里容易混淆的是“算法表”和“计算状态”。crc64.MakeTable(crc64.ECMA) 生成一张用于 CRC-64/ECMA 的表；crc64.New(table) 返回一个实现了 hash.Hash64 的对象；对这个对象多次调用 Write，等价于把多段输入连续接到同一条数据流上。

Sum64 返回当前累计的 uint64，不会把状态重置。需要给接口或日志输出时，再用 %016x 固定成 16 位十六进制，避免不同结果的展示宽度不一致。

用 CopyBuffer 边读文件边算 CRC64

如果目标是控制内存，关键改动不是把 ReadAll 换成另一种哈希函数，而是让读取器和哈希对象形成流式连接。下面的函数只保留一个 256 KiB 的工作缓冲区；文件无论是几十 MB 还是更大，都不会因为读取动作一次性复制到一个大切片里。

package main

import (
    "fmt"
    "hash/crc64"
    "io"
    "os"
)

func fileCRC64(path string) (uint64, int64, error) {
    // Open 只负责取得读取句柄，调用方要在返回前释放它。
    file, err := os.Open(path)
    if err != nil {
        return 0, 0, fmt.Errorf("open %s: %w", path, err)
    }
    defer file.Close()

    // ECMA 是算法表；New 返回可以持续 Write 的 Hash64 状态。
    hasher := crc64.New(crc64.MakeTable(crc64.ECMA))
    // 缓冲区大小固定，避免把整份文件展开到内存中。
    buf := make([]byte, 256*1024)
    copied, err := io.CopyBuffer(hasher, file, buf)
    if err != nil {
        // CopyBuffer 返回读取或写入链路遇到的第一个错误。
        return 0, copied, fmt.Errorf("copy %s: %w", path, err)
    }

    // Sum64 读取累计值；它不会清空 hasher 的内部状态。
    return hasher.Sum64(), copied, nil
}

func main() {
    checksum, bytesRead, err := fileCRC64("archive.data")
    if err != nil {
        fmt.Println("checksum failed:", err)
        return
    }
    // 固定 16 位输出，便于日志、比较和复制。
    fmt.Printf("bytes=%d crc64=%016x\\n", bytesRead, checksum)
}

这里的 copied 是实际送入哈希的字节数。成功时 io.CopyBuffer 返回的错误是 nil，不需要把正常的 EOF 当作失败；如果中途读取失败，函数会同时保留已经处理的字节数和原始错误。

固定缓冲区带来的内存差异可以怎样判断

两种写法的差别可以先用内存模型判断，而不是凭感觉说“流式更快”。io.ReadAll 的工作集会随着输入长度增加；CopyBuffer 只保留调用方提供的缓冲区和哈希状态，文件大小主要影响处理时间，不直接决定缓冲区容量。

如果要做真实的吞吐对比，应固定文件内容、存储介质、缓冲区大小和重复次数，再分别记录耗时、分配次数和峰值内存。本文的结论是资源边界：流式算法减少的是输入数据的驻留方式，并不保证在所有磁盘和 CPU 环境中都更快。

分段读取时不要为每段重新 New

CRC64 的增量特性适合分段下载或消息拼接。只要这些片段的逻辑顺序就是原始文件顺序，就应复用同一个 Hash64；每段重新 New 会得到多个独立校验和，不能直接把这些数值相加或拼接。

func checksumParts(parts [][]byte) uint64 {
    // 一个 Hash64 表示一条连续的数据流，片段顺序必须稳定。
    hasher := crc64.New(crc64.MakeTable(crc64.ECMA))
    for index, part := range parts {
        // hash.Hash.Write 按接口约定不会返回写入错误。
        if _, err := hasher.Write(part); err != nil {
            // crc64 的 Write 当前不会出错；保留分支可适配其他 Writer。
            panic(fmt.Errorf("write part %d: %w", index, err))
        }
    }
    // 所有片段写完后再取一次最终值。
    return hasher.Sum64()
}

在这个例子里，Write 的错误分支对 crc64 实现实际上不会触发，因为标准 hash.Hash 约定其 Write 不返回错误。但把顺序和生命周期写清楚，有助于以后替换为带错误的自定义写入器时不误用。

算法表和校验和能否直接互换

crc64.ISO 与 crc64.ECMA 是不同的多项式。发送端和接收端必须约定同一张表、相同的数据字节顺序和相同的起止范围；否则即使两边都使用 crc64.New，结果也不会相同。校验和用于发现传输或存储中的意外变化，不等同于密码学哈希，也不能替代签名或篡改防护。

• 文件范围是否包含头部、尾部和元数据，必须在协议里固定。
• ECMA 与 ISO 不要只用“CRC64”这个简称互相猜测。
• 比较结果时用同一数值格式；十六进制输出通常更适合日志和人工比对。
• 如果对端给的是 8 字节结果，要确认其字节序；Sum 的字节布局与 Sum64 的整数展示不是同一层概念。

常见问题

crc64.New 会不会把整个文件放进内存？

不会。New 只创建哈希状态；是否一次性读入内存取决于读取方式。使用 io.CopyBuffer 时，数据按缓冲区分块进入哈希。

为什么不能把每个分块的 CRC64 结果相加？

CRC 是按输入顺序递推的状态计算。分块结果不是普通可加的独立指标；要得到整个文件的结果，应把所有分块依次写入同一个 Hash64。

Sum64 调用后还能继续 Write 吗？

可以。Sum64 读取当前累计值，不会重置状态；继续写入后再次调用会得到包含新数据的结果。

应该选 ECMA 还是 ISO？

选择取决于对接协议或已有数据格式。若协议没有明确约定，不能只凭名称猜；先固定多项式、范围和字节序，再让两端使用一致实现。