Go海量字符串去重需分场景：千万级用map[string]struct{}但注意初始化、预扩容和key类型；布隆过滤器作前置拦截须配二次校验；超大文件用哈希分治+map精准去重，三者常混用。
Go 里做海量字符串去重，map[string]struct{} 不是不能用，而是到千万级就开始吃内存、GC 压力陡增；布隆过滤器能压到 1% 空间，但必须配二次校验，否则误判就丢数据。
map[string]struct{} 的真实开销和避坑点
它确实是单机去重最直接的方案，但“直接”不等于“无脑用”。关键在内存占用不是线性增长，而是受字符串长度、数量、GC 频率三重影响。
-
map[string]bool比map[string]struct{}多占几 MB 到上百 MB——bool占 1 字节，struct{}占 0 字节，千万级 key 差出真实带宽 - 结构体当 key 会编译失败：
map[MyStruct]struct{}报invalid map key type，因为含 slice、map 或 func 就不可比较 - 忘记
seen := make(map[string]struct{})初始化，运行时 panic；预估容量不足（比如make(map[string]struct{}, 1e6)却塞进 2e6 条），触发多次扩容，写入变慢 - 用
fmt.Sprintf("%v", s)构造唯一键极危险——Go 版本升级可能改变输出格式，导致同结构体算出不同 key
布隆过滤器上线前必须确认的三件事
它不是 map 的替代品，而是前置拦截器。上线前不核对这三点，轻则误判率翻倍，重则服务 OOM。
- 初始化参数不能按当前数据量填：
bloom.New(10_000_000, 0.001)表示“最多存 1000 万条、容忍千分之一误判”，不是“现在有 100 万条就填 100 万” -
filter.Test()返回false→ 绝对没出现过，可直接保留；返回true→ 只是“可能重复”，必须查Redis SET或本地map[string]struct{}确认，跳过这步等于主动丢数据 - 别自己实现布隆过滤器——用
github.com/yourbasic/bloom，它支持序列化，重启后可复用位图；手撸容易哈希函数质量差、位图大小算错、并发不安全
超大文件（>10GB）只能靠哈希分治，排序不是解法
内存装不下全部字符串，又不能依赖外部服务？排序 + 双指针看着简洁，实际不可行：100GB 文件根本没法在内存排序，外部排序 I/O 开销远高于分治。
立即学习“go语言免费学习笔记（深入）”；
- 核心是“相同内容必须进同一桶”：对每行算
hash(line) % N（比如N = 100），写入file_0到file_99 - 哈希函数必须确定性且分布均匀，推荐
fnv.New64a()或xxhash.Sum64()，别用string(len)这类弱哈希 - 若某小文件仍超内存（如
file_0达 15GB），说明数据倾斜，对该文件换另一个哈希函数递归拆分，比如再做hash2(line) % 10 - 每个小文件内用
map[string]struct{}去重，不是为了省空间，而是确保精准——布隆过滤器在这里不适用，因为最终结果要 100% 准确
真正难的不是选 map 还是布隆过滤器，而是判断哪一段数据允许误判、哪一段必须零误差；同一个系统里常要三者混用：布隆过滤器拦 99% 流量，map[string]struct{} 处理中等批量离线数据，哈希分治扛住原始日志归档——边界模糊处，才是工程落地的关键。
