Go hash.Hash 怎样一边计算摘要一边写文件

把文件与 hash.Hash 一起传给 io.MultiWriter，再让 io.Copy 向这个组合 Writer 写数据，就能在单次读取源流的过程中完成文件写入和摘要计算。建议使用 io.MultiWriter(f, h) 的文件优先顺序，并且只有复制、关闭都成功后，才把摘要当作完整文件的结果交给调用方。

Go 官方地址：https://go.dev/。标准库文档入口：https://pkg.go.dev/io、https://pkg.go.dev/hash。

文件写完为什么还要再读一次

假设一个导出接口拿到连续数据流，需要保存成文件并返回摘要。如果先保存再重新打开文件计算摘要，就多了一次读文件。源数据来自一次性网络响应时，更不能简单地让同一个 Reader 连续复制两次：第一次已经把它读到结束。

可以先判断需求究竟是“记录本次写入的字节”，还是“重新读取文件核对内容”。前者适合组合 Writer；后者属于另一项独立检查。本文处理前者，示例不读取整个文件进内存，也不宣称已经执行测试。

把文件与摘要计算器接到同一个 Writer

sha256.New() 返回实现 hash.Hash 的对象，它同时也是一个 Writer。文件 Writer 接收存储字节，摘要 Writer 累积这些字节；io.MultiWriter 负责把同一份写入数据交给两个接收者，而 io.Copy 连接源 Reader 和组合 Writer。

这里的“一边计算一边写”不是两个 goroutine 并行执行。MultiWriter 对一次写入依次调用其接收者，遇到错误就停止。它也不是事务，没有替接收者回滚的能力。这些规则见官方 io.MultiWriter 文档：https://pkg.go.dev/io#MultiWriter。

把复制和关闭错误纳入返回值

下面的原创函数适合保存一个新文件。目标存在就报错，不覆盖旧文件；源 Reader 由调用方提供，其关闭责任也属于调用方。函数管理自己创建的目标文件，并把关闭错误纳入最终结果。

package exportfile

import (
    "crypto/sha256"
    "encoding/hex"
    "fmt"
    "io"
    "os"
)

// SaveWithDigest 单次读取源流；目标必须不存在，避免覆盖已有文件。
// 失败时保留不完整文件供调用方处理，但不返回可用摘要。
func SaveWithDigest(path string, src io.Reader) (n int64, digest string, err error) {
    f, err := os.OpenFile(path, os.O_WRONLY|os.O_CREATE|os.O_EXCL, 0600)
    if err != nil {
        return 0, "", fmt.Errorf("创建目标文件: %w", err)
    }
    defer func() {
        // 关闭失败也属于写文件失败；已有复制错误保持为主错误。
        if closeErr := f.Close(); closeErr != nil {
            digest = ""
            if err == nil {
                err = fmt.Errorf("关闭目标文件: %w", closeErr)
            }
        }
    }()

    h := sha256.New()
    // 文件放在前面：文件本次写入失败时不再给摘要计算器写这一块。
    n, err = io.Copy(io.MultiWriter(f, h), src)
    if err != nil {
        return n, "", fmt.Errorf("复制数据: %w", err)
    }
    // Sum(nil) 取出当前摘要，不把输入重新哈希，也不重置状态。
    return n, hex.EncodeToString(h.Sum(nil)), nil
}

返回值中的 n 用于观察复制计数，不能在错误发生时单独作为完整性证明。复制失败时摘要为空；复制成功但关闭失败时，延迟函数也会清空摘要并设置错误。调用方必须先检查 err，再使用 digest。

文件优先并不能保证失败时文件和哈希前缀完全一致。如果文件只接受了当前数据块的一部分，MultiWriter 不会再向后面的哈希对象写这一块；文件可能比摘要状态多出这部分字节。因此，失败结果应整体判为不可用，不应通过颠倒参数顺序来掩盖问题。

本例保留失败时的目标文件，不自动删除它。调用方应记录失败状态，并按明确的业务策略清理或隔离部分文件；不要让下游把“路径存在”当作成功标志。对需要对外发布的文件，可设计临时文件和成功发布协议，但那是额外的生命周期管理，不是 MultiWriter 自带的功能。

摘要与文件不一致时先看写入位置

如果业务增加压缩、编码转换或缓冲，先问摘要到底要描述哪一层字节。哈希接在转换前，代表原始内容；接在转换后，代表实际交给存储层的编码内容。两者可能都合理，但不能拿其中一个去比较另一层文件。

本例没有缓冲 Writer。若改成 bufio.Writer，复制成功只说明写入它被接受，后续 Flush 仍可能失败；必须把 Flush 与文件关闭一并纳入成功条件。摘要值与错误状态不能脱离文件交付状态单独保存。

怎样确认自己的集成没有漏掉错误

在项目中接入时，可选一份已知字节样本：成功分支先检查错误为空，再检查返回计数与样本字节数一致，最后独立读取生成文件计算同算法摘要作对照。对照读文件只是读者的测试方法，不是主实现的第二次读源要求。

异常分支至少覆盖 Reader 在中途返回错误，以及目标创建失败。对存储抽象还应模拟写入失败、部分写入和关闭失败，确认业务不会把摘要和成功状态提前提交。本函数明确不覆盖已有文件，所以目标已经存在时应看到创建失败，而不是悄悄替换。本文没有运行这些检查，不提供虚构的日志或性能数值。

成功返回也不等价于断电后数据一定可恢复。对持久化有明确要求时，需要另外处理同步到存储、目录状态和平台差异；并确认文件没有随后被其他代码改写。摘要描述本次处理的字节，不会追踪未来修改。

常见问题与使用边界

Sum(nil) 会清空已经写入的状态吗

不会。Sum 返回当前摘要，状态保持不变；继续 Write 会继续累积。要复用同一个对象处理下一份独立文件，需先 Reset，或者更简单地为每个文件创建一个新对象。官方说明：https://pkg.go.dev/hash#Hash。

为什么不要把原始内容传给 Sum

Sum 的参数是摘要附加到的切片，不是需要计算的输入。输入必须通过 Write 或 io.Copy 写进 Hash；示例使用 Sum(nil) 获取纯摘要，再转换成十六进制文字。SHA-256 的结果是32字节，十六进制显示为64个字符，文档入口：https://pkg.go.dev/crypto/sha256。

多个文件能不能共用一个 Hash 并发计算

本方案应为每个文件使用独立 Hash。共享累积状态不仅涉及并发访问，还会把不同文件内容混进同一个摘要；不要仅因为文件支持并发方法，就推断整个组合 Writer 也适合并发写入。

落地时记住三个条件：源流只复制一次，摘要与文件描述相同的字节，所有写入收尾错误都被纳入结果。MultiWriter 解决的是写入组合，不替你提供事务、失败回滚或持久化承诺。