不能用os.ReadFile计算大文件哈希，因其会一次性加载全部内容到内存导致OOM，且可能读取截断内容使哈希错乱；必须用os.Open+io.Copy流式计算，内存恒定、错误可控、支持大文件可靠校验。
为什么不能用 os.ReadFile 计算大文件哈希
直接 os.ReadFile 读取几百 MB 甚至 GB 级文件，会把全部内容加载进内存，极易触发 OOM；更隐蔽的问题是：若文件正被写入（如日志轮转中），os.ReadFile 可能读到截断内容，导致哈希值错乱，去重失效。
必须改用流式计算：os.Open 打开文件句柄，再用 io.Copy 把内容“推”进哈希器，内存占用恒定在几 KB。示例：
h := sha256.New()
f, err := os.Open(path)
if err != nil { return nil, err }
defer f.Close()
_, err = io.Copy(h, f) // 注意检查 err 是否为 io.EOF 以外的错误
if err != nil { return nil, err }
sum := h.Sum(nil)
常见错误包括忽略 io.Copy 返回的 err（比如文件中途被删、权限变化），或忘记 defer f.Close() 导致 fd 泄漏。
空文件、硬链接、符号链接怎么统一处理
空文件哈希值不一致会导致“相同内容不同 key”——必须显式约定：所有空文件统一用 sha256.Sum256{} 的零值（32 字节全 0）作为哈希 key，而不是跳过或 panic。
立即学习“go语言免费学习笔记（深入）”；
硬链接和符号链接容易误判：
- 仅比对
os.Stat返回的Ino不够：不同设备上可能有相同 inode 号，必须同时检查Stat.Sys().(*syscall.Stat_t).Dev和Ino - 符号链接默认被
os.Open自动跟随，若需按“链接路径”去重（而非目标内容），得先os.Lstat判断是否为 symlink，再os.Readlink获取路径；若按内容去重，则直接os.Open即可
别用 os.Lstat 替代 os.Stat 去获取目标文件信息——它返回的是链接自身的元数据，不是目标文件的 inode。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
md5 还是 sha256？选错会影响去重可靠性
内部可信路径（如日志归档、本地缓存）且追求吞吐量，md5 足够快（实测 1GB 文件比 sha256 快约 1.8 倍），但碰撞已被实证攻破；用户上传、跨系统校验、长期存档等场景，必须用 sha256。
sha1 已被 Go 标准库标记为 insecure，禁止使用。
关键不在算法本身，而在于一致性：同一套系统里，哈希计算、存储、查询三处必须用完全相同的算法和编码方式。例如：
- 存数据库时用
hex.EncodeToString(sum[:]) - 建文件系统目录时用
sum[0:2] + "/" + sum[2:]分层 - 两处逻辑若不严格同步，查不到 key 是静默失败，不是报错
删除重复文件时如何避免误删原文件
核心原则是：保留哪个副本，不能只依赖 ModTime —— FAT32 不支持纳秒精度，os.Chtimes 也无法精确还原时间戳，排序结果不可靠。
更稳妥的做法：
- 按路径字典序排序后取第一个（
sort.Strings(paths)），其余标记为待删 - 或显式指定保留目录（如
--keep-dir ./originals），其他路径一律删除 - 务必提供
--dry-run模式，默认只打印将要删除的路径，不执行os.Remove - 真正删除时用
os.Remove（不是os.RemoveAll），并检查 error（如只读文件、权限不足）
真正麻烦的从来不是哈希计算，而是文件系统语义（mtime、inode、symlink）、并发访问（多个 goroutine 同时处理同一路径）、以及哈希 key 在内存 / DB / 磁盘路径间的映射一致性——这些地方出错，不会 panic，只会让去重静默失效。
