自建哈希函数对大文件去重几乎没用，因为手写哈希（如字节异或、取模）碰撞率飙升、结果不可靠，且性能远低于已高度优化的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–16goroutine），而非无限制启 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%，因为：
立即学习“go语言免费学习笔记（深入）”；
-
[32]byte是可比较的值类型，直接作 key，无逃逸、无 GC 压力 -
string作 key 需额外分配底层数组，每次hex.EncodeToString(sum[:])都触发一次内存分配 - 小文件多时（如 100 万个 1KB 文件），后者可能多占几百 MB 内存
- 输出日志时再转 string：
hex.EncodeToString(dupKey[:])，只在必要时做
真正容易被忽略的是：哈希结果本身不决定性能，怎么存、怎么读、怎么避免 I/O 乱序，才决定你跑完一整个目录要花 3 秒还是 3 分钟。
