Go crc64.MakeTable 生成的 Table 可以安全复用吗

可以复用，但要把“算法表”和“计算状态”分开看：crc64.MakeTable 返回的 *crc64.Table 可以作为只读共享对象，被多个并发任务引用；每个任务则应通过 crc64.New(table) 创建自己的 hash.Hash64。官方文档明确要求不要修改 Table 内容，而 Hash64 本身包含会随 Write 变化的状态，所以不能把同一个 Hash64 在 goroutine 之间混用。

Table 可以共享，Hash64 状态不能混用

我第一次把 CRC64 放进并发校验服务时，最容易混淆的是两个指针的职责。Table 只描述“怎样计算”，官方把它定义为表示多项式的 256-word table，并特别说明其内容不能修改；hash.Hash64 则是一次具体计算的累积状态，写入一批字节后，后续 Sum64 会依赖已经写入的内容。

因此推荐把表放在初始化位置，把哈希对象放到请求或任务函数内部：

package main

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

// crcTable 只在初始化时生成，后续只读复用，不要改写其内容。
var crcTable = crc64.MakeTable(crc64.ECMA)

// fileCRC64 为每次调用创建独立 Hash64，避免并发任务共享累积状态。
func fileCRC64(path string) (uint64, error) {
    file, err := os.Open(path)
    if err != nil {
        return 0, err
    }
    defer file.Close()

    var h hash.Hash64 = crc64.New(crcTable)
    // 文件字节持续写入当前任务自己的哈希对象，不把文件整体载入内存。
    if _, err := io.Copy(h, file); err != nil {
        return 0, err
    }
    // Sum64 只读取当前对象的累计结果，不会修改它的状态。
    return h.Sum64(), nil
}

这里可以安全复用的是 crcTable，不是 h。如果两个 goroutine 同时向同一个 h 调用 Write，它们会竞争同一份累积状态；即使程序没有立刻崩溃，也不能把结果当成两个独立输入的 CRC64。需要并发时，让每个任务调用一次 crc64.New(crcTable) 就够了。

并发复用的边界：共享只读数据，隔离可变状态

“Table 可以并发复用”是一个有前提的工程判断，不是说 crc64 的所有对象都可以无锁共享。更准确的关系是：算法表只读，多个 Hash64 读取它；Hash64 的累计值各自独立，分别接收自己的输入。

如果业务确实把 Table 暴露给多个组件，组件之间也只能把它当成只读配置。不要为了“动态切换算法”直接改写已有 Table；需要另一套算法时，生成另一张表，并让任务显式选择对应指针。

Checksum、New 和 Update 怎么选

这三个 API 都接收 *crc64.Table，但适用的输入形态不同。官方文档中，Checksum 直接返回一段数据的 CRC64；New 创建可持续写入的 hash.Hash64；Update 则是在已有 CRC 值上加入一段字节。

package main

import "hash/crc64"

// checksumSmall 适合数据已经在内存中的一次性计算。
func checksumSmall(data []byte, table *crc64.Table) uint64 {
    return crc64.Checksum(data, table)
}

// updateChunks 适合调用方已经维护累计 crc，并按块追加输入。
func updateChunks(crc uint64, chunks [][]byte, table *crc64.Table) uint64 {
    for _, chunk := range chunks {
        // Update 返回新的累计值；不要把不同任务的 crc 变量混在一起。
        crc = crc64.Update(crc, table, chunk)
    }
    return crc
}

文件、网络流或未知大小的数据，我更倾向 New + Write；小的内存切片用 Checksum 更直观；已有分块协议状态时，Update 可以减少额外的 Hash64 包装。无论选哪一种，Table 的复用规则不变：只读共享，不能修改。

最终判断：复用 Table，隔离 Hash64

可以把 crc64.MakeTable 的结果放到包级变量、服务对象或依赖注入容器中，让多个任务共同读取。真正需要避免的是两个误区：一是把同一个 hash.Hash64 当作全局单例，二是把“Table 不可修改”误解成“所有相关对象都不能并发使用”。

落地前只要问自己三个问题：共享的是否只是只读 Table？每个并发任务是否有自己的 Hash64 或 crc 值？输入是否需要持续写入而不是一次性切片？三个答案分别对应安全复用、状态隔离和 API 选择。

常见问题

多个 goroutine 同时调用 crc64.Checksum 可以吗？

可以在共享只读 Table 的前提下这样组织；每次调用只使用自己的输入和返回值，不共享可变 Hash64 状态。

能不能把 crc64.New(table) 返回的 Hash64 放进全局变量？

不建议。它会累计写入内容，跨请求共享会让不同输入的状态互相污染；应在每个任务内创建或从任务专属池中取得实例。

Table 被修改后会发生什么？

官方文档要求不要修改其内容。修改会破坏后续计算依赖的算法表，结果也不再有稳定的协议含义；需要另一种配置时应创建另一张 Table。