文件内容相似度去重不能用sha256/md5，因其雪崩效应无法识别语义相同但格式不同的文本；必须先定义业务层面的“相似”标准，再依数据类型选择归一化、AST解析或MinHash等对应方案。
直接说结论：文件内容相似度去重 ≠ 简单哈希比对，Go 标准库不提供现成方案，必须自己定义“相似”并选合适算法；硬上 sha256 只能判完全相同，对改写、缩进、注释差异的文本完全失效。
为什么不能用 sha256 或 md5 做相似度去重
这些哈希函数是雪崩设计的——哪怕一行末尾多一个空格，整个哈希值就彻底不同。日志、代码、配置等常见文本只要存在以下任一情况，sha256.Sum256 就会把语义相同的两行判为“不同”：
- 行尾空格或制表符差异
- 注释增删（如
// debug→ 删除该行） - JSON 字段顺序调整、key 大小写变化
- HTML/Markdown 中标签换行位置不同
- URL 参数顺序打乱但语义一致（
?a=1&b=2vs?b=2&a=1）
所以，相似度去重第一步不是写 Go 代码，而是明确业务中“什么算相似”：是忽略空白和注释的代码块？还是归一化 URL 后的请求路径？还是提取关键词向量？没有定义，就无法实现。
三种实用场景对应的具体做法
别从零造轮子。根据你手头数据类型，选最匹配的轻量路径：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
日志行 / 配置行 / URL 列表：先做字符串归一化，再用
map[string]struct{}去重
例如 URL，用net/url.Parse解析后清空RawQuery再按 key 排序重建查询参数；日志行用strings.TrimSpace+ 正则替换连续空白为单空格 + 去掉#.*$注释 -
源码片段 / Markdown 段落：用
go/parser（Go 代码）或blackfriday（Markdown）解析 AST，序列化关键节点（如函数名、参数列表、标题层级），再哈希
避免直接比对原始字符串，AST 能天然屏蔽格式差异 -
任意文本块（无结构）：用 MinHash + Jaccard 相似度，推荐
github.com/agnivade/levenshtein（编辑距离）或github.com/dustmop/simhash（局部敏感哈希）
注意：simhash对长文本效果好，但需预设分词粒度（如 4-gram）；levenshtein适合短文本（≤200 字符），超长会 O(n²) 超时
容易被忽略的坑：内存与顺序
相似度计算比纯哈希更吃资源，尤其在流式处理大文件时：
- 别用
ioutil.ReadFile读整个文件——几 MB 的文本就可能让simhash占用百 MB 内存；改用bufio.Scanner分块读，每块单独归一化+哈希 - 归一化后的 key 若仍含随机成分（如时间戳、UUID），得提前用正则替换为占位符（
re.ReplaceAllString(line, "{uuid}")），否则相似判定失效 - 想保留首次出现的原始行（而非归一化后形式），必须用
map[string]string存归一化key → 原始行，而不是map[string]struct{} - 并发处理多文件时，
sync.Map不支持遍历全部 key，若需汇总所有唯一内容，得额外用chan string收集结果再合并
真正难的不是写那几十行 Go 代码，而是花时间看样本、定归一化规则、测误判率。比如处理 Nginx 日志，"GET /api/v1/users HTTP/1.1" 和 "GET /api/v1/users?limit=10 HTTP/1.1" 算不算相似？这个判断不在代码里，在你的需求文档里。
