Golang构建基于文件哈希去重的数据存储引擎-Golang-PHP中文网

不能用os.readfile计算大文件哈希，因其会一次性加载全部内容到内存导致oom，且可能读取截断内容使哈希错乱；必须用os.open+io.copy流式计算，内存恒定、错误可控、支持大文件可靠校验。

golang构建基于文件哈希去重的数据存储引擎

为什么不能用 `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。

硬链接和符号链接容易误判：

仅比对 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。