Go中map[string]struct{}去重内存暴涨主因是字符串key的runtime开销被低估：每个key复制字符串头、指针、长度，并叠加哈希桶、GC元信息；1000万条50字节字符串实测超1.2GB。
map[string]struct{} 去重为什么内存暴涨
不是 map 本身慢，是字符串 key 的 runtime 开销被低估了。Go 的 map[string]struct{} 存储时，每个 key 都会复制一份字符串头（2个 uintptr）+ 底层数组指针 + 长度，再加上哈希桶、bucket 结构、GC 元信息——实测 1000 万条平均 50 字节的字符串，内存占用常超 1.2 GB。
常见误操作包括：
- 用
map[string]bool替代map[string]struct{}：每个bool占 1 字节，千万级多出上百 MB - 未对输入做归一化：
"abc\n"和"abc"被视为不同 key，strings.TrimSpace(line)必须加 - 复用 map 实例跨多次调用：没清空就继续塞，内存只增不减
布隆过滤器该不该上，怎么配参数
当去重集合稳定在千万级以上，且能接受「极小概率误判（false positive）但绝不漏判（false negative）」时，bloom.TestAndAdd() 是最轻量的前置筛子。它不存原始字符串，只维护位图，1000 万元素约 12 MB。
关键参数不能拍脑袋：
立即学习“go语言免费学习笔记（深入）”；
-
bloom.New(10_000_000, 0.01)表示预估存 1000 万条、容忍 1% 误判率；设小了误判飙升，设大了浪费内存 - 别用
github.com/smartystreets/goconvey/bloom：已多年未维护，用github.com/yourbasic/bloom（纯 Go，API 简洁）或github.com/willf/bloom（支持 Gob 序列化） - 绝对不要在循环里每次 new 一个过滤器：位图为空，
TestAndAdd()永远返回 false
超大文件（>50GB）必须分治，但哈希函数不能乱选
内存装不下全部 key 时，“分而治之”不是可选项，是唯一路径。核心约束只有一条：相同内容必须进同一个桶。这意味着哈希函数必须确定性、抗倾斜、且不依赖运行时状态。
推荐组合：
- 用
sha256.Sum32(line)或fnv.Hash32计算哈希值，再% N分桶（N=100～1000），比简单len(line) % N抗倾斜得多 - 每个桶单独加载、去重、flush 到临时文件；别把所有桶同时 load 进内存
- 若某桶仍超内存（比如单桶 15GB），说明数据严重倾斜，需对该桶换另一个哈希函数递归拆分，而不是扩大桶数
MinHash/SimHash 不是“去重开关”，而是相似度探针
如果你的目标是“删掉完全相同的行”，MinHash 和 SimHash 都不该出现在代码里。它们不解决精确去重，只回答“这两段文本有多像”。强行套用，结果要么漏删（相似但不等），要么误删（不相似却被判近似）。
真正该用它们的场景很窄：
-
MinHash：亿级短文本（每条 ≤100 字）中找 Jaccard 相似度 ≥0.8 的组，且必须配合char_shingles(text, width=5)和 LSH 加速 -
SimHash：网页/新闻标题去重，要求“改写后仍识别为重复”，但需后续汉明距离校验（如 ≤3 位差异才合并） - 两者都不可逆：你无法从签名还原原文，也无法删除某个签名对应的所有原文
最容易被忽略的点：所有概率型方案（布隆、MinHash、SimHash）都需要二次校验才能落地。线上系统里，bloom.TestAndAdd() == false 可以直发，但 true 后必须查 Redis 或 DB 才能决定是否丢弃——这一步漏掉，误判就直接变成线上事故。
