自建哈希函数对大文件去重几乎没用，因为手写哈希（如字节异或、取模）碰撞率飙升、结果不可靠，且性能远低于已高度优化的sha256或xxhash；真正瓶颈在i/o而非哈希计算，应优先优化流式读取、并发控制、文件大小预筛和路径遍历方式。

为什么自建哈希函数对大文件去重几乎没用

直接写个自定义哈希函数（比如按字节异或、取模、简单滚动哈希）来替代 crypto/sha256 或 xxhash，不仅不会提升性能，反而会破坏去重可靠性——碰撞率飙升，相同内容可能算出不同哈希，不同内容却偶然一致。Go 标准库的 sha256.New() 和第三方 xxhash.New() 已经是高度优化的汇编实现，单核吞吐常达 1–2 GB/s；而手写的纯 Go 哈希逻辑，哪怕只做一次 XOR 累加，在 100MB+ 文件上也常慢 3–5 倍，且无法利用 CPU 指令集加速。

真正影响性能的瓶颈从来不是哈希算法本身

实测表明，90% 以上的大文件去重耗时卡在 I/O 层：磁盘寻道、缓存未命中、文件系统锁、open/close 开销。哈希计算本身只占总时间 5–15%（SSD 上）或更低（HDD 上）。所以优化方向必须落在：

• 用 io.Copy 流式读取，避免 os.ReadFile 全量加载 → 内存恒定、不 OOM
• 控制并发数（8–16 goroutine），而非无限制启 worker → 防止磁盘队列打满、调度抖动
• 先按 os.Stat().Size 分组，只对同大小文件哈希 → 跳过 99% 明显不同的文件
• 跳过 os.ModeSymlink 和 os.ModeIrregular → 防止 open 失败或误读设备文件
• 用 filepath.WalkDir 替代 filepath.Walk → 更快、支持 filepath.SkipDir

想提速？换更快的哈希器，但别自己造

如果确实需要比 sha256 更快的哈希（比如日志归档场景），应直接引入成熟实现：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• github.com/cespare/xxhash/v2：非加密哈希，64 位输出，速度是 sha256 的 3–5 倍，抗碰撞性对内部去重足够
• github.com/lukechampine/blake3：加密级强度，速度接近 xxhash，适合需长期存档的场景
• 两者都支持流式接口：h := xxhash.New(); io.Copy(h, f); sum := h.Sum64()
• 切忌把 xxhash.Sum64() 当成“自建”——它是经过大规模验证的工业级实现，不是玩具代码

map key 用 [32]byte 还是 string？这个细节真吃性能

用 map[[32]byte][]string 存 sha256 结果，比 map[string][]string 节省内存 30–50%，查找快 10–20%，因为：

• [32]byte 是可比较的值类型，直接作 key，无逃逸、无 GC 压力
• string 作 key 需额外分配底层数组，每次 hex.EncodeToString(sum[:]) 都触发一次内存分配
• 小文件多时（如 100 万个 1KB 文件），后者可能多占几百 MB 内存
• 输出日志时再转 string：hex.EncodeToString(dupKey[:])，只在必要时做

真正容易被忽略的是：哈希结果本身不决定性能，怎么存、怎么读、怎么避免 I/O 乱序，才决定你跑完一整个目录要花 3 秒还是 3 分钟。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！