Go crypto/sha512怎样边读文件边计算 SHA-512怎样在批处理代码中减少额外分配

如果批处理程序要给一批文件计算 SHA-512，最稳妥的做法不是先调用 os.ReadFile，而是用 sha512.New() 创建一个 hash.Hash，让文件内容通过 io.CopyBuffer 分块写入。这样内存不会随着单个文件变大；在连续处理多个文件时，再把读取缓冲区和摘要暂存区放到循环外复用，就能减少重复分配。

官方地址：https://pkg.go.dev/crypto/sha512

这篇只讨论文件完整性摘要和批处理的内存行为。SHA-512 是哈希，不是加密；如果场景需要带密钥的认证，应改看 HMAC 等方案。

先看差别：整块 Sum512 和流式 hash.Hash

sha512.Sum512(data) 接收一个完整的 []byte，小消息或已经在内存中的数据用它很直接。问题在于大文件：为了得到这个参数，调用方通常要先把整个文件读进内存，文件大小和内存峰值就绑定在了一起。

sha512.New() 返回实现了 hash.Hash 的哈希器。它可以不断接收分块数据，直到文件读完，再调用 Sum 取出结果。两者得到的摘要规则相同，区别在输入数据是否需要一次性准备好。

实现核心：让文件内容分块进入 SHA-512

先写一个只负责单文件的函数。打开文件后立刻登记 defer Close，然后让 io.CopyBuffer 负责反复读取并调用 hash.Hash 的 Write。这里的读取缓冲区由调用方传入，批处理时就可以在多个文件之间复用。

package main

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

// hashFile 流式读取文件，返回固定长度的 SHA-512 十六进制结果。
func hashFile(path string, readBuf, sumBuf []byte) (string, error) {
	f, err := os.Open(path)
	if err != nil {
		return "", fmt.Errorf("打开 %s: %w", path, err)
	}
	defer f.Close() // 无论读取成功还是失败，都关闭文件描述符。

	h := sha512.New()
	if _, err := io.CopyBuffer(h, f, readBuf); err != nil {
		return "", fmt.Errorf("读取 %s: %w", path, err)
	}

	// sumBuf 的容量固定为 64 字节，避免 h.Sum(nil) 每次重新准备暂存切片。
	digest := h.Sum(sumBuf[:0])
	return hex.EncodeToString(digest), nil
}

这段代码没有把文件内容保存下来，io.CopyBuffer 只会反复使用 readBuf。SHA-512 的摘要长度固定为 64 字节，所以 sumBuf 可以按 sha512.Size 预留容量。hex.EncodeToString 仍会创建最终字符串，这是为了让批处理结果易于记录和比较；真正需要继续传递二进制摘要时，可以直接复制到 [sha512.Size]byte。

批量处理：把固定缓冲区放到循环外

减少额外分配的关键不在于把所有东西都做成全局变量，而是让一次批处理拥有自己的复用缓冲区。下面的示例顺序处理路径列表：每个文件都会创建新的哈希器，避免不同文件的内容串在一起；读取缓冲区和摘要暂存区则只创建一次。

// hashFiles 顺序处理一批文件，复用 I/O 与摘要缓冲区。
func hashFiles(paths []string) (map[string]string, error) {
	readBuf := make([]byte, 128*1024) // 128 KiB 只服务这一批顺序读取。
	sumBuf := make([]byte, 0, sha512.Size)
	results := make(map[string]string, len(paths))

	for _, path := range paths {
		// 每个文件都新建 hash.Hash，不能复用已经写入过内容的哈希器。
		digest, err := hashFile(path, readBuf, sumBuf)
		if err != nil {
			return nil, err // 保留带文件名的错误，调用方能定位失败项。
		}
		results[path] = digest
	}
	return results, nil
}

这里的复用有两个边界：readBuf 只能由当前顺序任务使用；如果改成多个 goroutine 并行处理，就要为每个并发 worker 准备独立缓冲区，或者用池管理生命周期。另一个边界是 sumBuf 不能在一次调用尚未完成时被另一个 goroutine 同时写入。

错误与结果：别把摘要计算和业务失败混在一起

文件不存在、权限不足、读取中断都应该作为错误返回，不能用一个空字符串伪装成摘要。调用方如果希望“单个文件失败但其余继续”，可以在循环层记录错误后继续；如果要求整批原子成功，则遇到第一个错误就返回。

func printDigests(paths []string) {
	readBuf := make([]byte, 128*1024)
	sumBuf := make([]byte, 0, sha512.Size)

	for _, path := range paths {
		digest, err := hashFile(path, readBuf, sumBuf)
		if err != nil {
			// 错误中带有文件路径，便于批处理日志定位输入项。
			fmt.Printf("跳过 %s：%v\n", path, err)
			continue
		}
		fmt.Printf("%s  %s\n", digest, path)
	}
}

如果摘要只是用于内部比较，可以少做一次字符串编码：让函数返回 [sha512.Size]byte，比较时用 ==，展示或写入清单时再编码。字符串格式适合日志、清单和跨进程传输，但不应因为方便打印就把它当作安全认证。

适用边界：SHA-512 能证明什么，不能证明什么

相同输入在相同算法下会得到相同摘要，因此它适合做下载文件、归档文件或批量产物的完整性比对。它不提供保密性，也不证明摘要来自某个可信发送者；攻击者如果可以同时替换文件和摘要，就能重新计算一份匹配值。

• 只需要检测传输或落盘内容是否变化：使用 SHA-512 或项目约定的其他哈希算法。
• 需要证明消息由持有密钥的一方生成：使用 HMAC 等带密钥的认证方案，不要把裸 SHA-512 当签名。
• 需要密码存储：使用专门的口令哈希方案，并遵循其参数和盐值要求，不要直接保存 SHA-512。

可以把本文的批处理模板记成一句话：文件用流式读取，哈希器按文件新建，I/O 缓冲区按批次复用，摘要只在需要时编码。

相关问题

为什么不能把一个 sha512.New() 用完后继续算下一个文件？

哈希器会保留此前写入的状态，继续写入会得到两个文件拼接后的摘要。每个文件都应创建新的哈希器，只有读取同一个逻辑对象的连续分块时才复用同一实例。

io.CopyBuffer 的缓冲区越大越好吗？

不是。缓冲区应结合文件系统、并发数和内存预算选择；更大的切片可能减少部分读取次数，但也会放大每个并发 worker 的内存占用。示例中的 128 KiB 是可调整的起点，不是固定性能结论。

SHA-512 结果为什么通常打印成 128 个十六进制字符？

SHA-512 摘要是 64 字节，每个字节通常用两个十六进制字符表示，所以文本形式是 128 个字符。二进制比较时不必先编码成字符串。