Go 批量算文件 SHA-256 时怎么优雅取消：做一个有并发上限的哈希小工具

归档文件夹里有几万份附件，需要给每个文件补一份 SHA-256 清单时，最容易写出的版本往往是遍历到一个文件就起一个 goroutine。小文件夹里它看起来没问题；文件一多，打开文件数、磁盘寻道和结果通道会一起失控。更麻烦的是，操作者按下 Ctrl+C 后，程序可能还在慢慢读完大文件，半天退不出进程。

先确定这个小工具要交付什么

目标不是做一个花哨的文件夹扫描器，而是把一个路径下的普通文件变成可核对的清单：每行包含相对路径和 SHA-256；遇到权限问题或文件被提前删除，也能明确知道是哪一个文件失败。命令约定如下：

go run . -dir ./archive -workers 3 -out checksums.txt

这类任务有两个边界。第一，哈希本身会占用 CPU，但机械盘或网络盘通常先被并发读取拖慢；第二，取消不是“马上杀掉所有 goroutine”，而是让还没开始的任务不再投递，让正在读的循环尽快返回。这里别急着把 worker 数调得很大，三个稳定读取者往往比三百个抢文件句柄的读取者更快。

准备文件夹扫描与任务类型

新建一个空文件夹后初始化模块。示例只处理普通文件，跳过软链接和文件夹，避免无意间跨到其他挂载目录。

mkdir filehash && cd filehash
go mod init example.com/filehash

任务里带上相对路径，输出时不用再猜文件来自哪里：

type job struct {
    full string
    rel  string
}

type result struct {
    rel string
    sum string
    err error
}

扫描函数要把 ctx.Done() 放在回调最前面。这样主程序收到中断后，不会继续向已经没人消费的任务通道写数据。

func walk(ctx context.Context, root string, jobs chan

把停止信号送进每个读取动作

不少代码只在拿到文件前检查一次 context。对于几个 GB 的镜像文件，这样取消依旧要等到 io.Copy 读完。更稳妥的做法是用固定大小缓冲区读文件，每一轮读取后看一次取消信号。

func hashFile(ctx context.Context, path string) (string, error) {
    f, err := os.Open(path)
    if err != nil { return "", err }
    defer f.Close()

    h := sha256.New()
    buf := make([]byte, 256*1024)
    for {
        if err := ctx.Err(); err != nil { return "", err }
        n, readErr := f.Read(buf)
        if n > 0 {
            if _, err := h.Write(buf[:n]); err != nil { return "", err }
        }
        if readErr == io.EOF { break }
        if readErr != nil { return "", readErr }
    }
    return hex.EncodeToString(h.Sum(nil)), nil
}

256 KiB 不是标准答案，只是一个容易观察的起点。大多数场景中，缓冲区从 32 KiB 提到 256 KiB 的收益会比继续增大 worker 数更直观。若文件夹在对象存储挂载或 NFS 上，先把缓冲区、并发数和耗时写入日志，再决定是否调整。

固定 worker 数比一文件一 goroutine 更稳

把任务通道交给固定 worker，再用 sync.WaitGroup 等待它们退出。每个 worker 都只负责“取任务、算哈希、交结果”这一条短路径；任何一处看到取消，就安静返回。收口协程只在所有 worker 退出后关闭 results，避免发送方和关闭方竞争。

func startWorkers(ctx context.Context, n int, jobs 

主函数里用 signal.NotifyContext 接住 Ctrl+C。扫描可以放进一个协程，结束时关闭 jobs；主 goroutine 只负责消费结果并写文件。对取消错误不要当成普通失败文件写进清单，否则用户会误以为文件损坏。

把结果写成可补跑的清单

输出不要直接用原文件名覆盖。先写到 checksums.txt.tmp，全部完成后再改名，能避免半截清单被下游脚本误用。这里的示例为了突出并发主线省略了排序；若下游依赖稳定顺序，可以先把结果收集到切片，按 rel 排序后统一写出。

okCount, failCount := 0, 0
for r := range results {
    if r.err != nil {
        if errors.Is(r.err, context.Canceled) { continue }
        fmt.Fprintf(os.Stderr, "failed %s: %v\\n", r.rel, r.err)
        failCount++
        continue
    }
    fmt.Fprintf(out, "%s  %s\\n", r.sum, r.rel)
    okCount++
}
fmt.Printf("done: %d files, %d failed\\n", okCount, failCount)

真正上线前建议做两次小验证：准备十来个不同大小的文件，人工删掉其中一个；再复制一个大文件并在中途按 Ctrl+C。前者应留下单文件错误，后者应快速停止且不会出现“向已关闭通道发送”的 panic。

容易踩到的四个坑

• 无限制启动 goroutine：文件数就是并发数，句柄上限和磁盘队列会先报警。
• 由 worker 关闭 results：多个发送者无法安全决定谁最后离开，统一由等待组收口。
• 忽略部分结果：批量任务出现一个坏文件很正常，应该让成功项和失败项都可追踪。
• 把取消视为损坏：取消表示操作者主动停止，不应污染失败统计和补跑名单。

相关问题

worker 数设置成 CPU 核数可以吗？

可以作为起点，但文件哈希还受磁盘、网络盘和文件大小分布影响。先试 2～4 个，再记录总耗时和 I/O 等待时间，比套公式可靠。

为什么不直接用 io.Copy 把文件送进哈希器？

它的写法更短，但在需要尽快响应取消时，不如显式读取循环容易插入检查点。对小文件或不需要取消的离线任务，io.Copy 完全合适。

哈希清单需要排序吗？

若用于版本比对、提交代码库或自动化核验，建议排序；若只做一次性盘点，边到边写能节省内存。

文件处理期间被修改会怎样？

得到的是读取窗口内的内容摘要。需要强一致时，应先冻结写入、对快照文件夹计算，或记录文件大小和修改时间后再复查。

收尾时看三件事就够了

这个小工具的价值不在 SHA-256 算法本身，而在任务数量大起来以后仍能可控地停止、定位失败并复用已完成结果。先限制并发，再把取消送到读取循环，最后让唯一的收口点关闭结果通道；这三处守住了，文件夹再大也不会把一次简单盘点变成难查的并发问题。