硬链接判定必须同时比对Dev和Ino字段，仅比Ino会跨设备误判；符号链接需先Readlink再Stat目标；小文件哈希优先sha256并流式计算；删除重复文件应按路径字典序保留首个、支持--dry-run；并发写map须避免竞态，推荐chan收集后合并。
为什么用 os.Stat 和 os.Lstat 区分不了硬链接？
硬链接指向同一 inode，os.Stat 返回的 sys.Stat_t.Ino 确实相同，但仅靠这个不能直接判定“可去重”——因为不同设备（Dev 字段）上的同 inode 号是巧合重复，不是真实硬链接。必须同时比对 Stat.Sys().(*syscall.Stat_t).Dev 和 Ino 才可靠。
常见错误是只比对 Ino，导致跨设备误判；或者用 os.Lstat 代替 os.Stat 去处理符号链接，反而绕过了真实目标的 inode。
- 硬链接判定必须同时检查
Dev+Ino - 符号链接应先用
os.Readlink获取路径，再os.Stat目标（如需递归解析） -
os.Lstat只在需要获取链接自身元信息时才用，比如判断是否为符号链接
用 crypto/md5 还是 crypto/sha256 计算文件指纹？
小文件（md5 速度快、内存占用低；但存在理论碰撞风险，不适合对一致性要求极高的场景。大文件（>10MB）建议用 sha256，虽然慢 10%–20%，但抗碰撞性强，且 Go 标准库的 sha256 实现已高度优化，实际差距可控。
更关键的是：不要一次性读入整个文件——要用 io.Copy 流式计算哈希，否则 1GB 文件会吃光内存。
- 流式哈希示例：
h := sha256.New() f, _ := os.Open(path) io.Copy(h, f) f.Close() sum := h.Sum(nil)
- 避免
ioutil.ReadFile+md5.Sum组合，尤其在批量处理时 - 若只对比“是否完全相同”，且信任文件系统（如 ext4/xfs），可用
os.Stat的Size+ModTime快速筛掉明显不同的文件，再哈希
如何安全删除重复文件而不误删原文件？
核心原则：保留最早创建（或最旧修改时间）的那个，其余标记为待删。但要注意：os.Chtimes 无法精确设置纳秒级时间，且 FAT32 文件系统不支持纳秒精度，所以不能依赖 ModTime 排序作为唯一依据。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
更稳妥的做法是按路径字典序排序后取第一个，或显式指定“保留目录”（如 --keep-dir ./originals），其余一律删除。
- 删除前务必打印完整路径，例如：
fmt.Printf("rm %q (duplicate of %q)\n", dupPath, keepPath) - 提供
--dry-run模式，默认不执行物理删除 - 避免用
os.RemoveAll删除单个文件——该函数设计用于目录，误传路径末尾带/会导致静默失败或删错 - 真正删除时用
os.Remove，并检查返回 error（如权限不足、只读文件）
并发哈希计算时为何 map[string][]string 会 panic？
多个 goroutine 同时写同一个 map 会触发运行时 panic：fatal error: concurrent map writes。这不是 race detector 警告，而是直接崩溃。
解决方式不是加锁（性能差），而是用 sync.Map 或更推荐的“分片 map + 读写锁”。但最简单有效的做法是：每个 goroutine 独立构建局部结果，最后由主 goroutine 合并。
- 不要在 goroutine 中直接往全局
map[string][]string写入 - 改用
chan map[string][]string收集结果，主 goroutine range channel 合并 - 如果必须高频更新，用
sync.Map，但注意其LoadOrStore返回值是value, loaded bool，别忽略loaded - 启用
go run -race是发现这类问题的最低成本方式
实际跑起来之后，最容易被忽略的是硬链接跨设备判断和哈希过程中的内存暴涨——这两处不提前设防，工具在真实环境里要么删错，要么 OOM。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
