核心结论：用os.open+io.copy+hash.hash流式计算文件哈希，避免os.readfile导致oom；需检查错误、defer关闭文件、统一处理空文件与符号链接，并根据安全需求选md5（快）或sha256（抗碰撞）。
Go 语言中如何用文件指纹实现去重存储
核心结论：靠 sha256.Sum256 或 md5.Sum 计算文件内容哈希值，以哈希值为 key 存储唯一文件副本，避免重复写入磁盘。关键不在“怎么算哈希”，而在于“怎么安全、高效地读大文件并抗碰撞”。
为什么不能直接 os.ReadFile 再哈希整个文件
对大文件（比如几百 MB 的日志或视频片段）调用 os.ReadFile 会一次性把全部内容加载进内存，极易触发 OOM；同时，哈希前必须确保读取完整且无截断——尤其当文件被并发写入时。
- 改用
os.Open+io.Copy到hash.Hash，流式计算，内存占用恒定（约几 KB） - 务必检查
err是否为io.EOF以外的错误，比如syscall.EBADF（文件被删）或syscall.EACCES（权限不足） - 若需支持“正在写入的文件”，加
filepath.WalkDir配合os.Stat检查Size()是否稳定，或用flock（Linux/macOS）临时加锁
sha256 和 md5 在去重场景下的实际取舍
MD5 碰撞已被实证攻破，但用于内部服务的非安全去重（如日志归档、缓存预热），只要不涉及恶意输入，md5 仍够用，且比 sha256 快约 1.8 倍（实测 1GB 文件）。
- 选
md5：只做内部可信路径去重，追求吞吐量，且能接受极低概率误判（md5.Sum输出 16 字节，key 更短，DB/FS 索引更紧凑） - 选
sha256：文件来源不可控（如用户上传）、或需与外部系统哈希对齐、或长期存档要求抗碰撞性 - 别用
sha1：已不推荐，Go 标准库虽保留但文档明确标注 “insecure”
去重逻辑落地时最容易漏掉的三件事
哈希值算出来只是第一步，真正卡住上线的是边界条件处理。
- 空文件必须有统一表示：建议统一用
sha256.Sum256{}的零值哈希（即 32 字节全 0），而不是跳过或 panic - 硬链接和符号链接要显式处理：默认
os.Open跟符号链接，但硬链接共享 inode；若需按“内容去重”，得先os.Lstat判断是否为 symlink，再os.Readlink解析或跳过 - 哈希 key 的存储格式要一致：比如存数据库时用
hex.EncodeToString(sum[:])，但文件系统中建目录时用sum[0:2]+/+sum[2:]分层，两处编码逻辑必须严格同步，否则查不到
真正麻烦的不是算法本身，而是文件系统语义（mtime、inode、symlink）、并发访问（多个 goroutine 同时处理同一文件路径）、以及哈希结果在不同层（内存、DB、磁盘路径）间的映射一致性。这些地方出错，不会报 panic，只会静默导致“该去重的没去重”或“不该删的删了”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
