io.copy是go计算大文件校验和最核心的流式机制，它天然适配hash.hash接口，全程不加载文件到内存，gb级文件仅占用固定约32kb缓冲区，配合sha256.new()实现简洁、健壮、零手动缓冲管理的生产级sha256计算。
io.Copy 是 Go 中计算大文件校验和最核心的流式机制，它天然适配 hash.Hash 接口，全程不加载文件到内存，GB 级文件也只占用固定 ~32KB 缓冲区。
用 io.Copy + sha256.New() 计算 SHA256
这是生产环境最推荐的组合：简洁、健壮、零手动缓冲管理。
-
io.Copy(hasher, f)内部已使用优化缓冲（默认 32KB），无需自己Read(buf)循环 - 必须检查
io.Copy的第二个返回值err—— 它可能来自磁盘 I/O 中断、权限变更或网络文件系统断连，不是“算错了”，而是“没读完” - 调用
hasher.Sum(nil)获取结果，不是hasher.Sum([]byte{})；前者复用内部切片，后者可能额外分配 - 十六进制编码用
hex.EncodeToString(hasher.Sum(nil))，别漏掉Sum(nil)后的[:]切片操作（虽然EncodeToString内部会处理，但显式更安全）
crc32.New 和 crc32.Checksum 怎么选
取决于数据是否已全部在内存中。
- 小字节切片（如配置头、协议帧）直接用
crc32.Checksum(data, crc32.IEEETable)，省事且无状态开销 - 大文件或流式来源（如
*os.File、http.Response.Body）必须用crc32.New(crc32.IEEETable)+io.Copy，否则无法避免内存爆炸 - 重复使用同一
hash.Hash32实例前，务必调h.Reset()，否则是累加而非重算 - 别传
nil表给crc32.New或crc32.Checksum，会 panic；crc32.IEEETable是最通用选择
校验失败时，先分清是读取错误还是哈希不匹配
错误日志里必须带原始路径和操作动词，否则线上排查无从下手。
-
io.Copy返回err != nil→ 是 I/O 层问题（文件被删、权限变、NFS 挂掉），此时哈希值无效，不应参与比对 -
n == 0且err == nil→ 是空文件，需按业务决定是否允许（有些场景空文件是合法状态） - 只有
err == nil且n > 0时，才进入哈希比对逻辑 - 比对原始字节用
bytes.Equal(sum1[:], sum2[:])，不用字符串==—— 防止空格、换行、大小写干扰，也规避时序攻击风险
多文件 / 分片 / 拼接场景怎么算整体校验和
不要合并文件再算，用 io.MultiReader 流式串联。
- 顺序必须严格一致：
io.MultiReader(f1, f2, f3)和io.MultiReader(f2, f1, f3)结果完全不同 - 如果文件列表来自用户输入或 API，先按路径名排序（
sort.Strings），再构造MultiReader -
MultiReader不会自动关闭内部 reader，每个*os.File仍需单独defer f.Close() - 任一文件读取出错（如
f1权限不足），io.Copy立即返回 error，后续文件不会读取 —— 这是正确行为，不是 bug
io.Copy，转而用 os.ReadFile、ioutil.ReadFile 或手动拼接 []byte。只要守住这条线，再大的文件，哈希计算也只是恒定内存+一次顺序 I/O。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
