生产级文件同步必须用sha256而非md5，因md5哈希碰撞风险真实存在；应流式计算、避免全量加载，结合os.samefile、大小时间初筛与块级增量哈希优化。
为什么用 sha256 而不是 md5 做文件比对
哈希碰撞风险是真实存在的，尤其在同步工具里，md5 已被证明可在实践中快速构造冲突文件。生产级文件同步必须用 sha256 或更强算法——Go 标准库的 crypto/sha256 开销可控，吞吐量足够日常使用（实测 100MB/s+），且无额外依赖。
常见错误：直接读整个文件进内存再哈希，大文件（如 >2GB）会触发 OOM；或用 md5.Sum 但没清零结构体，导致后续哈希值复用上一次结果。
- 始终用
sha256.New()创建新哈希器，别复用已计算过的hash.Hash实例 - 用
io.Copy流式写入哈希器，避免os.ReadFile全量加载 - 对空文件，
sha256输出固定值e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855，可作快速短路判断
os.SameFile 和 os.Stat 的误用场景
仅靠文件大小和修改时间（os.Stat 返回的 Size() 和 ModTime()）判断是否跳过同步，是高频出错点。NFS、某些云盘、Windows FAT32 下 ModTime 精度只有 2 秒，同秒内多次保存会导致时间戳一致但内容不同；大小相同更不可靠（大量不同内容可有相同字节长度）。
正确做法是：先用 os.SameFile 快速排除硬链接/同一文件，再比大小和时间做初筛，最后才走哈希比对。注意 os.SameFile 只能判断两个 *os.File 或两个 os.FileInfo 是否指向同一 inode，不能跨路径比较字符串路径。
立即学习“go语言免费学习笔记（深入）”；
- 不要对两个字符串路径直接调
os.SameFile，得先os.Stat拿到os.FileInfo -
os.Stat可能因权限失败，需显式检查err != nil && !os.IsNotExist(err) - 若源目标在同一文件系统，
os.SameFile成功率高；跨挂载点（如 /home 和 /mnt/usb）必然返回 false，此时必须哈希
增量哈希：如何避免重复计算已同步部分
全量重哈希每个文件效率低下，尤其当只改了末尾几 KB。Go 本身不提供“追加哈希”抽象，但可通过分块 + 哈希树（类似 rsync 的 rolling hash 思路）优化。简单实用的做法是：按固定块大小（如 4MB）读取，每块单独哈希，拼接成块哈希列表；同步时只比对块哈希，跳过完全相同的块。
这要求两端使用完全一致的分块逻辑（起始偏移、边界处理），否则哈希序列错位。常见坑是最后一块不足 4MB 时未单独处理，或用 io.ReadFull 导致 EOF 错误中断。
- 用
io.ReadAtLeast或手动循环读取确保每块至少读到指定大小，最后一块允许不足 - 块哈希建议用
sha256，但整个文件最终哈希仍需独立计算（防止块哈希拼接被篡改） - 块大小选 4MB 是权衡：太小（如 64KB）哈希开销占比高；太大（如 64MB）内存占用陡增且局部修改仍要重算整块
并发哈希时的 sync.Pool 误用
为减少 GC 压力，有人把 sha256.New() 放进 sync.Pool 复用。问题在于 hash.Hash 接口对象内部有状态（已写入数据长度、中间摘要等），若从池中取出未重置的实例，哈希结果必错。
Go 1.22+ 的 crypto/sha256 提供了 Sum(nil) 后自动重置的能力，但前提是调用前必须确保无残留数据。最稳妥的方式仍是每次新建，或用 sync.Pool 时严格配对 Get/Put 并在 Put 前调用 Reset()。
-
sync.Pool.New函数必须返回全新sha256.New()实例，不能返回复用对象 - 若用
sync.Pool，每次Get后立刻Reset()，Put前也必须Reset()（双重保险） - 实测显示：对中小文件（sync.Pool +
Reset()快 5%~10%，因对象分配成本已极低；真正受益的是超大文件流式哈希场景
哈希比对真正的复杂点不在算法本身，而在路径解析的符号链接循环、不同文件系统对硬链接的支持差异、以及并发下 stat/hasher 的生命周期管理——这些地方一不留神，同步就静默出错。
