大文件校验不能用os.readfile，因其一次性加载全部内容导致oom；必须用os.open+io.copy流式计算，配合sha256.new()或xxhash.sum64，按需选择完整性校验或快速抽样。
大文件校验为什么不能用 os.ReadFile
因为会直接 OOM。1GB 文件调用 os.ReadFile 就分配 1GB 内存，而校验本身只需要流式读取+哈希计算。标准库的 io.Copy 内部已优化缓冲区（默认 32KB），无需手动分块 Read + Write。
- 必须用
os.Open打开文件，defer f.Close()关闭句柄 -
hash.Hash实例（如sha256.New()）要每次新建，复用会导致结果错误 - 别用
md5.Sum([]byte)处理大文件——那是为小切片设计的，不支持流式输入
SHA256 和 xxhash 怎么选
目的决定算法：SHA256 是生产环境完整性校验的底线，xxhash.Sum64 是快速抽样比对的首选。两者不互斥，可组合使用。
- 端到端防篡改、审计、CDN 缓存验证 → 必须用
crypto/sha256 - 日志轮转检测、备份一致性快筛、硬链接自比排除 → 用
xxhash.Sum64，快 10 倍以上，无 GC 压力 -
xxhash需单独go get github.com/cespare/xxhash/v2，但体积小、依赖干净 - 别用
MD5：碰撞风险高，且 Go 生态里它常被误用于安全场景
头尾分段比对怎么避免 panic 和越界
直接 Seek(io.SeekEnd) 后读固定长度，容易触发 io.EOF 或越界 panic；用 io.SectionReader 是唯一稳妥方式。
- 头部：用
io.NewSectionReader(f, 0, 64*1024)读前 64KB - 尾部：先
f.Stat()拿Size()，再算偏移max(0, size-64*1024)，传给io.NewSectionReader -
io.SectionReader自动截断超出范围的读取，返回实际字节数 +io.EOF，不会 panic - 读尾部时若需按行边界对齐（如日志），得倒查
\n或\r\n，最多回溯 4KB，否则可能卡死在超长行
校验失败时怎么定位是读错了还是内容真不同
io.Copy 的返回值和 error 必须显式检查，否则 I/O 错误会被静默吞掉，你以为“哈希一致”，其实是没读完就结束了。
- 检查
err != nil：磁盘断连、权限变更、NFS 挂载失效都会在这里暴露 - 检查
n == 0：空文件或打开失败后意外进入 Copy，会产生有效哈希但逻辑异常 - 对比哈希时别用字符串
==：用bytes.Equal(sum1[:], sum2[:])，避免编码引入空格、大小写、填充等干扰 - 客户端传来的哈希（如 header 中的
X-Expected-SHA256）必须先hex.DecodeString，并检查解码 error —— 非法字符或奇数长度会直接失败
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
