直接比较文件内容会出错,因大文件读入内存导致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 权限语义,会静默失败
删除重复文件时如何避免误删
用户最怕的不是“没删干净”,而是“删错了”。真正的安全策略不是加确认提示,而是设计不可逆操作的前置保护。