Go 怎么计算大文件 SHA256：边读边计算的写法

Go 计算大文件 SHA256，关键不是把文件读成 []byte 再调用 sha256.Sum256，而是让文件流持续写入 sha256.New() 返回的哈希状态。标准库示例也是用 io.Copy 连接文件和哈希对象，因此内存占用不会随着文件大小线性增长。

最小可用写法是：os.Open 打开文件，sha256.New 创建状态，io.Copy 边读边写入，确认复制没有错误后再用 h.Sum(nil) 输出 32 字节摘要。

边读边算的核心调用链

sha256.New() 返回一个实现了 hash.Hash 的对象，它同时具备写入数据和取出当前摘要的能力。文件本身只作为 io.Reader，哈希对象作为 io.Writer，两者通过 io.Copy 连接起来。

package checksum

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

func FileSHA256(path string) (string, error) {
	f, err := os.Open(path)
	if err != nil {
		return "", fmt.Errorf("open %q: %w", path, err)
	}
	defer f.Close()

	h := sha256.New()
	if _, err := io.Copy(h, f); err != nil {
		return "", fmt.Errorf("read %q: %w", path, err)
	}
	return hex.EncodeToString(h.Sum(nil)), nil
}

这里没有创建与文件等大的字节切片。io.Copy 反复从文件读取小块数据，再调用哈希对象的 Write 更新内部状态；调用 Sum(nil) 只是在最后取出当前结果，不会清空这个状态。返回字符串前使用 hex.EncodeToString，便于写入日志、数据库或和外部校验值比较。

把打开、复制和摘要输出分成三个错误边界

文件摘要最容易出错的地方，是只关注最终字符串而忽略过程。os.Open 失败时没有输入；io.Copy 报错时只读到了部分内容；只有复制成功后，h.Sum(nil) 才有资格作为完整文件的摘要。

不要写成“无论 io.Copy 是否报错都返回 h.Sum(nil)”。部分内容也能产生一个合法的 SHA256 值，但它代表的是截断输入，不代表目标文件。需要对外返回校验结果时，建议同时返回读取字节数，或把它写入带有文件名、大小和错误字段的结构体。

大文件的缓冲区与内存边界

默认的 io.Copy 已经适合大多数文件摘要场景。只有需要复用缓冲区、统一内存上限，或者要在复制过程中观察字节数时，才显式使用 io.CopyBuffer。缓冲区是临时工作空间，不是用来保存完整文件。

func FileSHA256WithCount(path string, buf []byte) (sum string, n int64, err error) {
	f, err := os.Open(path)
	if err != nil {
		return "", 0, err
	}
	defer f.Close()

	h := sha256.New()
	n, err = io.CopyBuffer(h, f, buf)
	if err != nil {
		return "", n, err
	}
	return hex.EncodeToString(h.Sum(nil)), n, nil
}

// 调用方可以在多个文件之间复用同一块缓冲区。
buf := make([]byte, 128*1024)
sum, n, err := FileSHA256WithCount("backup.tar", buf)

io.CopyBuffer 接受空缓冲区时会自行分配；传入零长度但非 nil 的切片则不符合其约定。固定 128 KiB 只是一个工程示例，不是 SHA256 的硬性要求，真正的值应结合文件系统、并发量和内存预算决定。若 Reader 或 Writer 自己实现了更高效的读写接口，CopyBuffer 也可能不会使用这块缓冲区。

用摘要做文件校验时的判断清单

摘要值适合验证“读到的内容是否与期望一致”，但比较前要先统一表示方式。SHA256 的原始结果是 32 字节，转成小写十六进制后是 64 个字符。不要把带空格、换行或前缀的外部文本直接和结果比较。

func SameSHA256(actual, expected string) bool {
	return strings.EqualFold(strings.TrimSpace(actual), strings.TrimSpace(expected))
}

这段比较函数使用 strings 包；实际接入时还应先校验期望值是否为 64 位十六进制文本。

如果期望值来自不可信输入，先检查它是否恰好是 64 位十六进制文本，再进行比较；如果还要防止比较时间侧信道，应把文本解码成字节后使用适合该场景的常量时间比较函数。普通备份文件的完整性检查则重点放在“读取成功、字节数符合预期、摘要相等”这三个条件上。

常见问题

sha256.Sum256 能不能直接处理大文件？

它接收的是完整的 []byte，因此调用方需要先把数据放进内存。大文件应使用 sha256.New，通过 io.Copy 或多次 Write 流式更新。

为什么不能把 io.EOF 当作 io.Copy 的成功结果？

io.Copy 把源读到 EOF 视为正常结束，成功时返回的错误是 nil。调用方只需检查 err != nil；不应要求它返回 EOF。

计算摘要后还需要关闭文件吗？

需要。摘要完成不等于文件资源自动释放，使用 defer f.Close() 可以覆盖正常返回和读取失败路径。

把摘要计算放在完整性校验的最后一环

对大文件而言，最稳的实现就是让数据保持流式：打开文件后把内容写入哈希状态，读取成功才取摘要，输出前统一成可比较的十六进制文本。这样既控制了内存，也能把“文件打不开”“只读了一半”和“摘要不匹配”区分开，后续接入上传、备份或缓存去重流程时更容易定位问题。