直接比较文件内容会出错，因大文件读入内存导致OOM和GC停顿，且空格、换行、BOM、编码差异易致误判；应改用哈希比对并辅以inode与ModTime双重校验。
为什么直接比较文件内容会出错
用 os.ReadFile 读取两个大文件再用 bytes.Equal 比较，看似简单，但实际会吃光内存、卡死程序。1GB 文件读进内存就是 1GB 占用，还可能触发 GC 频繁停顿。更隐蔽的问题是：空格、换行符、BOM、编码差异（如 UTF-8 vs UTF-8-BOM）会让内容“看起来一样却比对失败”。
- 小文件（bytes.Trim 去除首尾空白，且限定只处理文本类（避免二进制文件误判）
- 大文件一律跳过全文读取，改用哈希——但别用
md5，它碰撞概率高且不抗恶意构造；生产环境请用sha256 - 注意：同一文件硬链接的
os.Stat().Size和os.Stat().Sys().(*syscall.Stat_t).Ino相同，可先用 inode 快速去重，省掉 90% 的哈希计算
如何安全地计算大文件 SHA256
不能把整个文件 load 进内存再算哈希，得流式读取。关键点不是“会不会写 io.Copy”，而是缓冲区大小和错误传播逻辑。
- 缓冲区设为
32 * 1024（32KB），太小导致系统调用过多，太大无意义（现代 SSD 顺序读已很高效） - 必须检查
hash.Hash.Write的返回值，某些磁盘错误或权限问题会导致写入中断，但sha256.Sum256不报错，会静默产出错误哈希 - 示例核心片段：
h := sha256.New() f, _ := os.Open(path) defer f.Close() buf := make([]byte, 32*1024) for { n, err := f.Read(buf) if n > 0 { if _, writeErr := h.Write(buf[:n]); writeErr != nil { return [32]byte{}, writeErr } } if err == io.EOF { break } if err != nil { return [32]byte{}, err } } return h.Sum([32]byte{}), nil
怎么处理中文路径和特殊字符文件名
Windows 和 macOS 对 Unicode 路径支持较好，Linux 默认 ext4 也支持 UTF-8 文件名，但问题出在 Go 的 filepath.WalkDir 行为上：它底层调用 readdir，不解析编码，遇到非法 UTF-8 字节序列会直接跳过该目录项，且不报错。
- 用
filepath.WalkDir时，务必在DirEntry.Name()上做utf8.ValidString检查，无效则记录日志并跳过，否则可能漏掉一批文件 - 不要用
strings.Contains做路径过滤（比如排除.git），而要用filepath.Base+filepath.Clean后比对，否则/foo/bar/../.git/config会被绕过 - 如果目标是跨平台工具，禁止依赖
os.Chmod修改权限来“标记重复文件”，Windows 不支持 Unix 权限语义，会静默失败
删除重复文件时如何避免误删
用户最怕的不是“没删干净”，而是“删错了”。真正的安全策略不是加确认提示，而是设计不可逆操作的前置保护。
立即学习“go语言免费学习笔记（深入）”；
- 永远保留最早修改时间（
ModTime）的那个文件，其余才标记为候选删除——用os.Stat获取时间，别信文件名里的日期 - 删除前必须调用
os.SameFile再次比对源路径与目标路径是否指向同一 inode，防止符号链接导致“删了原文件” - 提供
--dry-run模式，输出将要删除的绝对路径，并附带其哈希值和大小，方便人工抽检；默认不启用删除，必须显式传--delete - 不要用
os.Remove直接删，改用os.Rename移到临时隔离目录（如$HOME/.dupclean_trash），7 天后自动清空——这是最后兜底
真正难的不是算哈希或遍历目录，而是当两个文件 sha256 相同却一个能打开一个打不开时，你得判断是文件损坏、权限问题，还是哈希碰撞——这时候必须 fallback 到逐块 memcmp，但没人会真这么干。所以工程上，我们选择信任哈希，同时用 inode 和 ModTime 做双重校验，把风险控制在可解释范围内。
