Go 怎样边读文件边计算摘要

在 Go 里边读文件边计算摘要，最实用的写法不是先用 os.ReadFile 把全部内容装进内存，而是把文件句柄当作 io.Reader，把 sha256.New() 返回的哈希对象当作 io.Writer，再交给 io.Copy 持续搬运字节。这样文件大小主要影响处理时间，不会让一次性字节切片跟着文件一起膨胀。

官方文档：https://pkg.go.dev/crypto/sha256

先把文件摘要的核心链路看明白

文件摘要的关键不是“把文件变成字符串”，而是让哈希状态对象依次接收文件中的全部字节。os.File 提供读取能力，sha256.New 创建一个实现了 hash.Hash 的状态对象，io.Copy 负责从 Reader 读取并写入 Writer，最后通过 Sum(nil) 取出已经累计的摘要字节。

这个关系可以概括为：文件是输入，哈希对象是持续更新的状态，摘要是最终输出。哈希对象不需要知道文件路径，也不需要把全部文件内容保存下来。

用 os.Open 与 sha256.New 计算 SHA-256

下面这个函数接收文件路径，返回十六进制形式的 SHA-256 摘要。它没有创建与文件大小相同的 []byte，因此适合大文件、上传前校验和分块处理前的完整内容确认。

package main

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

// fileSHA256 按流读取文件，避免把整个文件一次性放入内存。
func fileSHA256(path string) (string, error) {
    // 打开失败时直接返回，不能继续对一个无效文件句柄做复制。
    file, err := os.Open(path)
    if err != nil {
        return "", fmt.Errorf("打开文件失败: %w", err)
    }
    defer func() {
        // 读取阶段的错误由调用方处理；这里负责兜底释放文件描述符。
        _ = file.Close()
    }()

    // hash.Hash 同时实现 io.Writer，Write 会更新内部摘要状态。
    hasher := sha256.New()
    if _, err := io.Copy(hasher, file); err != nil {
        // 读取或写入哈希状态失败时，不返回部分摘要。
        return "", fmt.Errorf("计算文件摘要失败: %w", err)
    }

    // Sum(nil) 返回当前状态的摘要字节，hex.EncodeToString 便于保存和比较。
    return hex.EncodeToString(hasher.Sum(nil)), nil
}

func main() {
    // 示例路径只是调用入口，实际项目中应由参数或业务对象提供。
    digest, err := fileSHA256("./assets/archive.zip")
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println(digest)
}

sha256.New 返回的是可持续写入的哈希状态，而不是已经算好的值；每次 io.Copy 写入一段数据，状态就随之更新。最后的 Sum(nil) 不会把文件内容重新读取一遍，hex.EncodeToString 只是把 32 字节摘要转换成便于日志、数据库或接口传输的十六进制文本。

打开错误、复制错误和 Close 怎么处理

这类函数最容易被忽略的是错误归属。os.Open 失败通常意味着路径、权限或文件状态有问题；io.Copy 失败则可能来自读取中断或底层 I/O 错误。两者都应该返回错误，而不是返回一个看起来完整的摘要。

示例使用 defer file.Close() 保证正常返回和异常返回都释放文件描述符。若业务必须确认关闭动作本身是否成功，可以把函数改成具名返回值，在复制成功后显式关闭并合并 Close 错误；对只读文件来说，常规场景优先保证句柄不会泄漏。

func fileSHA256WithCloseError(path string) (digest string, err error) {
    // 仍然按流打开文件，避免 ReadFile 造成额外内存占用。
    file, err := os.Open(path)
    if err != nil {
        return "", fmt.Errorf("打开文件失败: %w", err)
    }

    hasher := sha256.New()
    if _, err = io.Copy(hasher, file); err != nil {
        // 复制失败时先关闭句柄，再保留真正的读取错误。
        _ = file.Close()
        return "", fmt.Errorf("计算文件摘要失败: %w", err)
    }

    // 关闭只读文件通常不出错，但仍把异常作为调用失败向上返回。
    if err = file.Close(); err != nil {
        return "", fmt.Errorf("关闭文件失败: %w", err)
    }
    return hex.EncodeToString(hasher.Sum(nil)), nil
}

如果采用第一段里的匿名 defer，代码更短，也更不容易在新增分支时忘记释放资源；如果关闭错误对业务有明确意义，再选择显式关闭版本。不要为了追求形式上的“所有错误都返回”而让成功路径重复关闭同一个文件。

需要进度或旁路处理时使用 TeeReader

有时摘要不是唯一目标，还需要统计已经读取的字节数、更新进度条或把同一数据交给另一个 Writer。这时可以把文件 Reader 包装成 io.TeeReader：它读取上游数据后写入指定 Writer，读取和写入是同步关系，没有额外的内部缓冲。

type byteCounter struct {
    total int64
}

// Write 只累计收到的字节数，不保存文件内容。
func (c *byteCounter) Write(p []byte) (int, error) {
    c.total += int64(len(p))
    return len(p), nil
}

func fileSHA256WithProgress(path string) (string, int64, error) {
    // 文件仍然作为流输入，哈希对象仍然只保存摘要状态。
    file, err := os.Open(path)
    if err != nil {
        return "", 0, fmt.Errorf("打开文件失败: %w", err)
    }
    defer func() {
        // 函数只读文件，关闭动作放在返回路径统一处理。
        _ = file.Close()
    }()

    hasher := sha256.New()
    counter := &byteCounter{}
    stream := io.TeeReader(file, io.MultiWriter(hasher, counter))
    if _, err := io.Copy(io.Discard, stream); err != nil {
        // TeeReader 的旁路 Writer 出错时，io.Copy 会收到对应的读取错误。
        return "", counter.total, fmt.Errorf("读取并计算摘要失败: %w", err)
    }

    // 所有字节经过 TeeReader 后再取摘要，total 可用于进度或审计记录。
    return hex.EncodeToString(hasher.Sum(nil)), counter.total, nil
}

这里的 io.MultiWriter 让每次读取的数据同时写给哈希对象和计数器；io.Discard 表示业务只关心旁路 Writer 的处理结果，不需要再把数据保存到第三个目标。若只需要摘要，不要为了“看起来更流式”而额外套 TeeReader，直接 io.Copy(hasher, file) 更直观。

SHA-256、摘要和文件签名不是一回事

crypto/sha256 用于计算 SHA-224 和 SHA-256 摘要，hash 包提供的是哈希函数通用接口。摘要适合做内容指纹、缓存键组成部分或传输后比对，但它本身不证明“文件来自某个可信主体”，也不提供加密意义上的保密性。

如果需求是密码存储、数字签名或抗离线猜测，应使用与场景匹配的密码哈希、签名方案或密钥管理机制。单纯把文件算成 SHA-256 文本，不能替代这些安全设计。

几个容易踩到的边界

第一，不要在循环中重复创建哈希对象，否则每一段数据会得到独立摘要，最后无法代表整个文件。第二，不要忽略 io.Copy 的错误，也不要在错误发生后继续发布或保存摘要。第三，摘要比较应比较相同算法、相同字节内容产生的结果，文件名、修改时间和摘要不是同一类信息。

如果输入来自网络上传、压缩包或管道，思路仍然一样：只要对象实现 io.Reader，就可以把它接入哈希 Writer。需要限制读取范围时，可以在外层使用 io.LimitReader，但要明确这时计算的是限定范围的摘要，而不是整个输入。

常见问题

Go 计算大文件摘要会不会占用同样大的内存？

使用 os.Open 加 io.Copy 时不会把完整文件放进一个字节切片，内存主要由 I/O 缓冲、运行时和业务自身分配决定。

为什么不直接用 sha256.Sum256 计算文件？

sha256.Sum256 接收的是一段完整的 []byte，适合已经在内存中的小数据；文件流场景用 sha256.New 更自然，可以持续接收 Reader 的内容。

io.Copy 结束时需要把 EOF 当成错误吗？

不需要。正常读到文件末尾时，io.Copy 会返回成功；真正需要处理的是复制过程中出现的其他读取或写入错误。

如何把摘要保存到数据库？

通常保存固定算法名、十六进制摘要和文件大小等元数据，并在写入前确认计算过程没有返回错误。若摘要用于安全认证，还要另行设计签名和密钥管理。

总结

Go 边读文件边计算摘要的最小可靠方案就是 os.Open、sha256.New 和 io.Copy：文件按流进入哈希状态，成功后再通过 Sum(nil) 取出摘要。只需要摘要时保持链路简单；需要进度或旁路处理时再引入 TeeReader，并继续把所有读取错误向上交给调用方。