千万级字符串去重不能只靠map[string]struct{}，因其内存开销剧增（实测1000万条约1.2GB），而布隆过滤器仅需约12MB，虽允许极小误判但绝不漏判，适合作为轻量前置筛子，精确去重仍需接map或数据库二次校验。
为什么千万级字符串去重不能只靠 map[string]struct{}
内存爆掉是第一个信号：实测 1000 万条平均 50 字节的字符串，map[string]struct{} 占用超 1.2 GB。这不是理论值，是 runtime 实际分配——哈希桶、指针、GC 元信息全算进去。布隆过滤器同一量级只需约 12 MB，代价是允许极小概率误判（false positive），但**绝不漏判（false negative）**。
关键判断点就一个：你的业务能否接受“这个字符串*可能*见过”，但必须保证“这个字符串*绝对没见*过”时才放行？比如防重复入库、跳过已处理消息，那就适合；如果要求 100% 精确去重，布隆过滤器只能当第一道筛子，后面还得接 map 或数据库查重。
选哪个 Go 布隆库？别踩 gonum.org/v1/gonum/stat/distuv 这个坑
gonum 库里根本没有布隆过滤器——这是常见误解。真正稳定、生产可用的主流选择只有两个：
-
github.com/yourbasic/bloom：纯 Go，无依赖，API 极简，bloom.New(uint64(n), 0.01)直接按预期最大元素数n和误判率0.01初始化，内部自动算最优位图大小和哈希函数数 -
github.com/willf/bloom：支持GobEncode/GobDecode持久化，但注意NewWithEstimates()参数顺序是先元素数、再误判率，填反了误判率会失控
别碰 github.com/smartystreets/goconvey 里的实验性实现，已多年未维护；也别手撸——哈希独立性难保障，hash/fnv 单 hash 不够，多 hash 必须用 seed 隔离，yourbasic/bloom 内部用双 hash 推导，经压测验证可靠。
立即学习“go语言免费学习笔记（深入）”；
TestAndAdd() 是去重核心，但别在循环里反复 New()
TestAndAdd() 是原子操作：既判断又插入，返回 true 表示“已存在（或误判）”，false 表示“确定是新的”，此时你才该做后续处理（如写入 DB、发消息）。
常见错误：
- 每次循环都
new一个过滤器 → 位图永远空，全当新数据，完全失效 - 先
Test()再手动Add()→ 竞态下两个 goroutine 同时通过Test()，然后都Add()，导致重复处理
正确姿势：全局复用一个 *bloom.Bloom 实例，确保并发安全（yourbasic/bloom 默认线程安全）；初始化时 n 必须填你未来最多塞多少个唯一项（不是当前数量），p 填可接受误判率（如 0.001 表示千分之一），填小了位图爆炸，填大了误判飙升。
误判后怎么安全二次验证？别把 Test() 当最终结论
Test() 返回 false 可以直接放行（一定新）；但返回 true 只表示「很可能存在」，必须接一层真实存储校验，否则会丢数据。
典型组合是：BloomFilter → Redis SETNX（带 TTL）→ 最终 DB。重点：
- 校验必须用带原子性的操作，比如
SETNX，避免并发写入冲突 - 不要在
Test()为true时直接跳过后续逻辑——那是误判导致的漏处理，不是布隆本身的错，而是兜底逻辑没写严 - Redis key 的 TTL 要设合理，避免长期占用内存，也别太短导致频繁穿透
最易被忽略的点：布隆过滤器本身不负责去重，它只负责快速拦截。所有“存在性”判断结果，都得由下游真实存储拍板。漏掉这层，再小的误判率也会放大成线上事故。
