md5.Sum 更快更安全因其是值类型、栈上计算且避免误用；流式处理需用 hash.Hash 接口；同步须防竞态与覆盖，校验失败常因资源泄漏、读取截断或换行符差异。
为什么 md5.Sum 比 md5.Sum([]byte{}) 更快且更安全
Go 的 md5.Sum 是值类型，直接在栈上计算并返回固定长度的 [16]byte；而手动调用 md5.Sum([]byte{}) 容易误写成先 md5.New() 再 io.Copy()，但忘了 Sum(nil) —— 这会导致返回空切片，校验值永远为 0。
- 必须用
sum := md5.Sum(fileBytes); hash := sum[:]或sum := md5.Sum(fileBytes); hex.EncodeToString(sum[:])，不能对sum取地址再转切片（会逃逸） - 大文件别一次性读进内存：
os.Open+io.Copy(hash.Hash, file)+hash.Sum(nil)才是正确流式做法 - 注意：
md5.Sum不接受io.Reader，只能用于已知字节；流式场景必须用hash.Hash接口
同步时怎么避免“源文件刚改完、目标还没写完就被覆盖”
典型竞态：源文件正在被写入（如日志追加），你却把它整个拷过去，结果目标得到的是一个中间态脏数据。这不是 MD5 能解决的问题，得靠文件状态和原子操作。
- 先用
os.Stat检查源文件ModTime和Size，若 2 秒内变动过，跳过本次同步（或加重试逻辑） - 写目标前，先写到临时路径（如
dst.tmp），os.Rename替换原文件——Linux/macOS 下是原子的，Windows 需确保同磁盘 - 千万别用
os.Create直接覆写：万一写到一半中断，原文件就丢了
MD5 校验失败却不报错？检查这三处硬编码陷阱
常见现象：两个文件明明内容一致，hex.EncodeToString(sum1[:]) 和 hex.EncodeToString(sum2[:]) 却不等。问题往往不在算法本身。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
os.Open后没defer f.Close()→ 文件句柄泄漏，后续读取可能失败但没显式错误 - 用
ioutil.ReadFile（已弃用）读大文件 → 内存爆掉或静默截断（尤其 Windows 上默认限制 2GB） - 忽略文件末尾换行符差异：文本文件在不同系统下换行符不同（
\nvs\r\n），MD5 必然不同；同步前应明确是否需 normalize 行尾
跨平台同步时 filepath.Walk 返回路径格式不一致怎么办
Windows 返回 C:\a\b.txt，Linux 返回 /a/b.txt，直接拼接路径做 MD5 key 会导致同一文件在不同系统算出不同哈希值，无法比对。
立即学习“go语言免费学习笔记（深入）”；
- 统一用
filepath.ToSlash(path)转成正斜杠格式（如C:/a/b.txt），再参与哈希或映射键构造 - 别用
strings.ReplaceAll手动替换，filepath.ToSlash处理 UNC 路径和盘符更可靠 - 如果要做增量同步，建议把路径哈希（
sha256.Sum256([]byte(filepath.ToSlash(p)))）作为唯一 key，避免路径字符串直用带来的兼容性问题
