必须用io.Copy流式计算SHA256，因os.ReadFile易OOM，且Go无sha256.File()；需os.Open→sha256.New()→io.Copy三步，配合错误检查与defer关闭文件。
io.Copy 是流式计算文件 SHA256 的核心，不是可选项，是唯一安全路径。用 os.ReadFile 读大文件再哈希，几百 MB 就可能 OOM；GB 级文件直接触发系统 kill。Go 标准库没提供 sha256.File() 这种“捷径”，你必须自己搭流水线：打开句柄 → 创建哈希器 → 流式写入。
为什么必须用 io.Copy 而非手动 Read + Write
手动分块读取再喂给 hasher.Write() 看似可控，实则冗余、易错、还慢：
- 要自己管理缓冲区（大小、复用、清零），
io.Copy内部已用 32KB 最优缓冲，且自动处理读错误中断 - 漏检查
Read返回的n, err，磁盘满或 NFS 断连就静默失败 - 多一层循环和切片操作，GC 压力上升，吞吐反而下降
- 并发场景下若复用同一
hasher实例又忘了Reset()，哈希值会累加而非重算
io.Copy(hasher, file) 一行就完成全部逻辑，错误统一在返回值暴露，且天然支持 io.Reader 所有变体（比如 http.Response.Body 或 bufio.NewReader(file)）。
sha256.New() 和 sha256.Sum256() 别混用
两者类型不兼容，语义完全不同：
-
sha256.New()返回hash.Hash接口，适合流式写入（io.Copy、Write()），最终调Sum(nil)得[]byte -
sha256.Sum256([]byte(s))直接返回固定大小结构体[32]byte，仅适用于小数据（如字符串、token），不能用于文件流 - 误把
Sum256结果当hash.Hash传给io.MultiWriter会编译失败 - 误对
Sum256结果调.Sum(nil)会得到空哈希——它根本不是运行时哈希器
sha256.New()，别图省事抄错模板。
校验失败时最容易被忽略的三个点
算法本身几乎不会出错，问题全在边界环节：
- 服务端返回的 SHA256 值带前缀（如
SHA256: abcd...或sha256-abcdef...），没用strings.TrimSpace()和strings.TrimPrefix()清理就直接比对，必然失败 - 对方提供的是 Base64 编码（常见于 HTTP
Digest头或 CSPscript-src），却用hex.DecodeString()解码，panic 或结果错乱；必须用base64.StdEncoding.DecodeString() - 比对时用
==比两个十六进制字符串，看似没问题，但若其中一方含不可见空格或大小写不一致（如Avsa），就失效；更稳妥是解码成[]byte后用bytes.Equal()
os.Stat().Size() 非零，再开读。
断点续传中同步校验的硬性约束
下载中途断掉再继续，不能等整个文件写完再算哈希，必须边写边校：
- 打开文件必须用
os.O_CREATE | os.O_WRONLY，禁用os.O_APPEND—— 后者无视Seek()，强制写末尾，断点续传直接失效 - 先
os.Stat()获取已写长度，再file.Seek(offset, io.SeekStart)并验证返回值等于offset，不等说明文件被篡改或并发冲突 - HTTP 请求头必须带
Range: bytes=1024-，服务端响应必须是206 Partial Content，否则续传逻辑崩塌 - 写入与哈希必须原子同步：
io.Copy(io.MultiWriter(file, hasher), resp.Body)，不是分别io.Copy(file, ...)和io.Copy(hasher, ...)
chunk_index 拼接——网络丢包、重复发送、时钟漂移都可能导致顺序错乱。每片必须独立校验，失败则重传该片，不是跳过。
流式哈希真正的复杂点不在代码长度，而在所有环节的误差容忍度为零：文件句柄没关、Seek 没验、Range 头漏写、Base64/hex 解码选错、比对方式不防侧信道……任一环节松动，校验就形同虚设。 
