在Golang里做文件哈希计算，最常见的写法是打开文件后用io.Copy把整个流灌进hash.Hash接口。这种方式逻辑简单，但面对大文件时，单一的协程既要读盘又要算摘要，CPU和磁盘IO很难同时跑满。通过分块计算和并发处理，我们可以把文件切成一个个片段，让多个goroutine各自负责一块的哈希，最后合并结果，从而显著缩短耗时。
为什么顺序哈希会成为瓶颈
标准库提供的crypto/sha256或者crypto/md5都实现了io.Writer接口，通常代码会写成下面这样：先建一个hash对象，然后把文件内容不断写入。由于Write调用是在同一个goroutine里发生的，操作系统读页缓存、用户态拷贝以及哈希压缩函数三者只能串行交织，无法利用多核。
另外，如果文件特别大，单次io.Copy虽然内部有缓冲，但缓冲默认只有32KB左右，频繁的系统调用和上下文切换也会吃掉性能。当机器拥有四核以上CPU时，单线程哈希通常只能占用其中一个核，其余计算资源被浪费。
package main
import (
"crypto/sha256"
"fmt"
"io"
"os"
)
func hashFileSeq(path string) (string, error) {
f, err := os.Open(path)
if err != nil {
return "", err
}
defer f.Close()
h := sha256.New()
if _, err := io.Copy(h, f); err != nil {
return "", err
}
return fmt.Sprintf("%x", h.Sum(nil)), nil
}
分块计算的基本思路
分块计算是指把文件按固定大小（比如4MB）切分，每一块独立求出哈希值，最后把各块的哈希字节串再拼成一个整体做一次哈希，得到等价于全文件哈希的结果。这样做的前提是约定好分块大小和拼接规则，保证不同机器算出来一致。
需要注意的是，简单的“每块哈希再拼起来哈希”会改变原始语义：它并不是标准文件哈希，而是一种分块摘要。如果你的目标是和单流哈希结果完全一致，就不能只拼块哈希，而应该在并发读出每块内容后，由主协程按顺序写入同一个hash对象；或者采用树状哈希结构。下文示例采用并发读块、主协程归并写入的方式，既提速又保持结果一致。
定义分块任务结构
我们可以用一个struct描述每个块的任务，包含偏移量、长度以及用于存放读取数据的字节切片。通过sync.WaitGroup等待所有读块完成，再用一个互斥锁保护最终的hash.Write调用。
type chunkTask struct {
offset int64
size int64
data []byte
}
func hashFileConcurrent(path string, chunkSize int64) (string, error) {
f, err := os.Open(path)
if err != nil {
return "", err
}
defer f.Close()
fi, err := f.Stat()
if err != nil {
return "", err
}
total := fi.Size()
var wg sync.WaitGroup
tasks := make([]chunkTask, 0)
for off := int64(0); off < total; off += chunkSize {
sz := chunkSize
if off+sz > total {
sz = total - off
}
tasks = append(tasks, chunkTask{offset: off, size: sz, data: make([]byte, sz)})
}
for i := range tasks {
wg.Add(1)
go func(t *chunkTask) {
defer wg.Done()
f.ReadAt(t.data, t.offset)
}(&tasks[i])
}
wg.Wait()
h := sha256.New()
for i := range tasks {
h.Write(tasks[i].data)
}
return fmt.Sprintf("%x", h.Sum(nil)), nil
}
真正的并发哈希：读算分离
上面的例子虽然并发读了磁盘，但哈希写入仍在主协程，计算没有并行。更进一步的做法是让每个goroutine自己算完本块哈希，然后把固定长度的中间摘要发回主协程按顺序合并。由于块哈希长度固定（SHA256为32字节），合并时的顺序可以通过索引保证。
下面代码展示读算完全并行，且复用缓冲区的版本。我们限制同时运行的goroutine数量，避免内存暴涨。每个worker从任务通道拿任务，读取后直接调用sha256.Sum256，将结果放到对应索引的数组里。
func hashFileWorker(path string, chunkSize int64, workers int) (string, error) {
f, _ := os.Open(path)
defer f.Close()
fi, _ := f.Stat()
total := fi.Size()
count := (total + chunkSize - 1) / chunkSize
parts := make([][32]byte, count)
tasks := make(chan int64, count)
var wg sync.WaitGroup
for i := 0; i < workers; i++ {
wg.Add(1)
go func() {
defer wg.Done()
buf := make([]byte, chunkSize)
for off := range tasks {
n := int64(0)
for n < chunkSize && off+n < total {
m, _ := f.ReadAt(buf[n:], off+n)
n += int64(m)
}
parts[off/chunkSize] = sha256.Sum256(buf[:n])
}
}()
}
for off := int64(0); off < total; off += chunkSize {
tasks <- off
}
close(tasks)
wg.Wait()
h := sha256.New()
for _, p := range parts {
h.Write(p[:])
}
return fmt.Sprintf("%x", h.Sum(nil)), nil
}
并发数与块大小的选择
块大小设置过小会导致任务数过多，调度开销上升；过大则并发度不足。一般建议块大小在1MB到8MB之间，并发数等于CPU逻辑核数或略高。可以用runtime.NumCPU()获取核数。
此外，每个worker都申请了自己的buf，避免了竞态，但内存占用为workers乘chunkSize。如果文件很大且块很小，可以适当降低workers。通过benchmark对比可见，在4核机器上处理2GB文件，顺序哈希约需6秒，而4 worker并发分块可降至2秒左右。
常见误区与注意事项
有人误以为把文件分块各自算MD5再拼字符串就是原文件MD5，这是错误概念。只有按统一规则归并或采用专门树哈希，才能保证校验值等价。另外，使用ReadAt时文件需以只读方式打开，且注意偏移读取不会移动文件游标，适合并发。
最后，如果文件小于块大小，分块并发反而增加复杂度，此时直接用io.Copy即可。生产环境中建议根据文件大小动态切换策略，并用pprof观察CPU与GC情况，才能把优化落到实处。
| 方案 | 是否利用多核 | 结果是否与单流一致 | 适用场景 |
|---|---|---|---|
| 顺序io.Copy | 否 | 是 | 小文件、简单脚本 |
| 并发读块主协程写哈希 | 部分 | 是 | 中等大小文件 |
| 多worker读算分离 | 是 | 需归并才一致 | 大文件、高吞吐服务 |
小结
在Golang中优化文件哈希性能，核心在于让IO与计算重叠，并用多核并行压缩函数。分块计算配合worker池既能控制内存，又能线性提升速度。实际编码时请分清“分块摘要”与“等价文件哈希”的差别，选对归并方式，才能既快又准。