大文件应逐块流式哈希比对，避免OOM；推荐sha256，块大小64KB，需重置hash、按实际长度计算末块哈希，用io.Copy+hash.Hash更健壮，差异可精确定位到字节偏移，须先比文件大小，Windows加O_SEQUENTIAL提升性能。
大文件逐块哈希比对，别直接读全量
直接用 os.ReadFile 读几个 GB 的文件会 OOM，Go 的 runtime 常见报错是 runtime: out of memory。必须流式处理，按固定块（比如 64KB）读取并计算哈希，边读边比。
- 推荐用
sha256，碰撞概率低，标准库原生支持；md5虽快但不推荐用于校验一致性 - 块大小选 64KB（
65536）是个平衡点：太小增加 syscall 开销，太大内存占用上升 - 两个文件必须用相同块大小、相同偏移起始位置比对，否则哪怕内容一致也会误判
- 注意文件末尾不足一块时，要以实际读取长度计算哈希，不能补零或截断
用 io.Copy + hash.Hash 实现稳定流式哈希
别自己写循环读 bufio.Reader，容易漏处理 EOF 或 partial read。标准库的 io.Copy 在配合 hash.Hash 时更健壮，它自动处理短读和边界。
- 示例核心逻辑：
h := sha256.New() f, _ := os.Open("a.bin") defer f.Close() io.Copy(h, f) // 自动按内部 buffer 流式写入 hash sumA := h.Sum(nil) - 但这是全文件哈希——你要分块，就得手动控制
io.ReadFull或用io.LimitReader配合hash.Hash - 关键点：每次新块前必须调用
hash.Reset()，否则哈希值会累加 - 避免用
fmt.Sprintf("%x", sum)转字符串比对，直接比[]byte更快更安全
发现差异后快速定位到具体偏移位置
仅知道“两文件不同”没用，用户真正需要的是“从第几个字节开始不一样”。逐块哈希比对天然支持定位——只要某一块哈希不等，前面所有块都一致，差异起始位置就是该块的起始偏移。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 假设块大小为
chunkSize = 65536，第i块（从 0 开始）不匹配，则差异始于int64(i) * chunkSize - 注意：如果文件长度不同，最后一块长度不等，即使内容相同，哈希也必然不同——需先比文件大小，再比块
- 若只想确认是否一致，比到第一处不等就
return false, offset，不用继续 - 不要用
strings.Index或正则在二进制数据里找差异，那是文本思维，二进制必须按块/字节比
Windows 下注意 os.O_RDONLY | os.O_SEQUENTIAL 提升性能
在 Windows 上打开大文件，默认缓存策略可能引发大量随机 IO。加上 os.O_SEQUENTIAL 提示系统做顺序预读，实测能提升 2–3 倍吞吐。
立即学习“go语言免费学习笔记（深入）”；
- Linux/macOS 不支持该 flag，需运行时判断：
if runtime.GOOS == "windows" { flag |= os.O_SEQUENTIAL } - 别忽略
os.Stat获取文件大小——它是 cheap syscall，能提前排除长度不同的情况，省下全部哈希计算 - 并发比对多个块看似合理，但磁盘 IO 是瓶颈，多 goroutine 反而加剧寻道，单协程顺序读更稳
- 测试时用
dd if=/dev/urandom of=test1.bin bs=1M count=512生成真实大文件，别用空文件或小文件验证逻辑
实际跑起来你会发现，最耗时的环节往往不是哈希计算，而是磁盘读取本身；而最容易被忽略的，是文件末尾块长度不一致时的哈希处理逻辑——这里一错，整个比对结果就不可信。
