不能直接用md5.sum处理几百gb文件，因其需一次性加载全部字节到内存导致oom；必须使用hash.hash接口（如md5.new()）配合io.copy流式计算，内存恒定且支持断点续传与进度反馈。
为什么不能直接用 md5.Sum 处理几百 GB 的文件
因为 md5.Sum 默认把整个文件读进内存再计算，不是流式处理。你传一个 200GB 的 ISO 文件，程序大概率直接 OOM，连错误都来不及打印就崩溃了。
真正可行的做法是用 hash.Hash 接口配合 io.Copy 或分块 Read，边读边喂给哈希器。Go 标准库所有校验和类型（md5.New、sha256.New 等）都实现了这个接口。
- 必须用
h := md5.New()创建实例，而不是md5.Sum([]byte{}) - 文件要以只读 +
os.O_RDONLY打开，避免 mmap 或缓冲干扰流式行为 - 别用
ioutil.ReadFile—— 它内部就是全量加载，哪怕你只是想“试算一小段”
如何让校验和计算支持断点续算和进度反馈
大文件传输常中断，重头算 checksum 成本太高。核心思路是：把文件按固定块大小（比如 1MB）切片，每块单独算 hash，最后组合成 Merkle-style 根哈希，或直接拼接各块摘要。
这样上传中断后，只需重传并重算未完成的块，服务端也能并行验证。
- 块大小建议设为
1024 * 1024（1MB），太小增加 IO 开销，太大削弱断点粒度 - 用
bufio.NewReaderSize(f, blockSize)控制每次读取上限，避免底层 syscall 一次读太多 - 记录已处理字节数到临时文件（如
.checksum.state），格式为纯文本：offset: 123456789 - 恢复时用
f.Seek(offset, io.SeekStart)跳过已处理部分，再继续io.Copy(h, reader)
客户端和服务端怎么对齐校验逻辑才不会“算出两个结果”
常见坑是两端用了不同哈希算法、不同块大小、甚至不同字节序（比如误把 int64 offset 当作网络字节序处理）。最稳妥的方式是把校验参数作为传输元数据显式协商。
例如，在 HTTP header 中带：X-Checksum-Algorithm: sha256、X-Checksum-ChunkSize: 1048576；或者在上传前先 POST 一个描述 JSON：
{
"filename": "data.tar.zst",
"size": 32212254720,
"checksum_algorithm": "sha256",
"chunk_size": 1048576
}
- 服务端必须校验
chunk_size是否在允许范围内（如 64KB–4MB），防止恶意超小分块拖慢性能 - 算法名必须严格匹配 Go 的
crypto/*包注册名（"md5"、"sha256"、"sha512"），不接受别名如"SHA-256" - 如果客户端发的是 base64 编码的摘要，服务端解码前先 trim 空格和换行 —— 有些 curl 命令会自动加 \n
为什么用 sha256 而不是 adler32 或 crc32 做完整性校验
adler32 和 crc32 是校验码（checksum），不是密码学哈希（cryptographic hash）。它们设计目标是快和检错，不是抗碰撞 —— 攻击者能轻易构造出不同内容但相同 crc32 的文件。
尤其当传输链路涉及不受信中间节点（比如 CDN、代理、网关），必须用 sha256 或更强算法。Go 里选 sha256 是因为它在速度和安全性之间平衡得最好，sha512 在大文件上反而略慢（因内存带宽瓶颈）。
- 别用
hash/crc32.Checksum替代crypto/sha256，除非你明确只要本地磁盘 IO 错误检测 -
sha256输出长度固定 32 字节，base64 编码后是 44 字符，比md5的 32 字符更难被暴力猜解 - 如果业务要求 FIPS 合规，必须用
crypto/sha256（标准库实现通过了 FIPS 140-2 验证），而第三方 MD5 实现通常不满足
真正麻烦的不是算 hash，而是确保两端对“同一个字节流”在“同一分块策略下”喂给“同一算法”。任何一环错位，校验就失效。细节藏在 open 模式、seek 位置、buffer 边界、编码方式里，而不是算法本身。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
