因为 crc32.Checksum 要求一次性把全部数据加载进内存，对 GB 级文件会直接 OOM；必须用 crc32.New 创建 hash.Hash32 实例流式计算，支持分块写入且仅维护 4 字节状态。
为什么 crc32.Checksum 不能直接用于大文件流？
因为 crc32.Checksum 要求一次性把全部数据加载进内存，对 GB 级文件会直接 OOM。真正该用的是 crc32.New 返回的 hash.Hash32 接口——它支持分块写入，底层只维护 4 字节状态。
常见错误是把 io.Copy 和 crc32.Checksum 混用，比如先读一遍算 CRC，再读一遍传给下游，白白多一次 I/O。正确做法是用 io.TeeReader 或自定义 io.Reader 在读取时同步计算。
- 必须用
crc32.New(crc32.MakeTable(crc32.Castagnoli))（推荐 Castagnoli 表，比 IEEE 更抗突发错误） - 不要用
crc32.ChecksumIEEE处理流，它是静态函数，不保存中间状态 - 如果文件来自 HTTP 响应体，注意
resp.Body只能读一次，tee 是刚需
如何用 io.TeeReader 边读边算 CRC？
io.TeeReader 是最轻量的方案：它包装一个 io.Reader，每次 Read 时自动把数据写入指定的 io.Writer（比如你的 crc32.Hash），不缓存、不复制、零额外内存开销。
hash := crc32.New(crc32.MakeTable(crc32.Castagnoli))
reader := io.TeeReader(file, hash)
_, err := io.Copy(io.Discard, reader) // 实际中可替换为写入目标
if err != nil {
return 0, err
}
return hash.Sum32(), nil
- 确保在
io.Copy完成后再调用hash.Sum32()，中途调用会得到中间值 - 如果目标是上传到对象存储（如 S3），可以把
io.Discard换成http.Request.Body对应的写入器 -
io.TeeReader不处理读取错误传播，需自己检查err是否来自底层 reader
重试逻辑必须隔离 CRC 计算与传输失败
CRC 校验本身不该重试——它只是哈希计算，无副作用；重试应该发生在「传输 + 远端校验」环节。典型错误是把 CRC 计算包进 for 循环，导致每次重试都重复读文件、重复计算，浪费 CPU 和磁盘 I/O。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
正确结构是：先一次性算出本地 CRC → 启动传输 → 若远端返回 CRC 不匹配或网络失败，才重试传输（而非重算）。
- 把 CRC 结果作为元数据随请求发送（如 HTTP Header
X-Content-CRC32: 0x1a2b3c4d） - 服务端收到后，在写入前校验，失败返回
400 Bad Request或409 Conflict，明确区分网络超时和校验失败 - 重试次数建议设为 3，指数退避（如 100ms、300ms、900ms），避免雪崩
注意 os.Open 和 io.Seeker 对重试的影响
如果传输中断需要重试，且文件句柄已关闭，下次重试就得重新 os.Open —— 这没问题；但若想复用同一个 *os.File，就必须用 file.Seek(0, io.SeekStart) 回到开头。而很多非本地文件（如 HTTP body、管道）根本不支持 Seek。
- 判断是否可 seek：
_, ok := file.(io.Seeker)，不可 seek 就别试图重用 reader - 用
os.OpenFile(path, os.O_RDONLY, 0)而非os.Open，前者更明确语义，也方便后续加syscall.Fadvise预读优化 - 大文件场景下，
os.File的默认 buffer（如bufio.NewReader）可能影响性能，但 CRC 计算本身不依赖 buffer 大小
真正容易被忽略的是：CRC 值本身不保证内容未被篡改，只防意外损坏；若需防恶意修改，必须升级为数字签名（如 RSA-SHA256）。流式 CRC + 重试解决的是传输丢包、磁盘静默错误这类问题，不是安全边界。
