Go语言中海量字符串数据去重时的布隆过滤器实现

因为map[string]struct{}在千万级以上字符串去重时内存开销剧增（实测1000万条约1.2GB），而布隆过滤器仅需约12MB，以允许极小概率误判为代价实现高效存在性判断，且绝不漏判，适合作为轻量前置筛子。

说到海量字符串去重，比如日志去重、爬虫URL去重、实时流判重这些场景，很多人第一反应就是map[string]struct{}。但一旦数据量冲到千万级，内存开销会迅速失控。一个平均50字节的字符串，在map里实际占用的远不止50字节——哈希桶、指针、runtime开销统统要算进去。实测1000万条数据，1.2GB内存说吃就吃。布隆过滤器就不一样了，固定大小的位图加上多个哈希函数，空间压到一个可预测的范围里。同样是1000万元素，典型配置下只需要大概12MB。代价是允许极小概率的误判，但绝不漏判。

这就引出一个关键判断：如果你的业务能接受“这个字符串可能见过”，但必须保证“这个字符串绝对没见”过才放行——比如防重复入库、跳过已处理消息——布隆过滤器就很合适。反过来，如果业务要求100%精确去重，那它只能当第一道轻量筛子，后面还得接map或者数据库查重。

选哪个Go布隆库？

有个常见误解，以为gonum库里带了布隆过滤器，其实没有。真正稳定、生产可用的主流选择是github.com/yourbasic/bloom和github.com/willf/bloom。前者更轻量，纯Go、无依赖；后者支持序列化，但默认不启用CGO。至于github.com/smartystreets/goconvey里的实验性实现，已经很多年没人维护了，别碰。

实操建议是这样的：

• 新项目优先用yourbasic/bloom：API简洁，直接bloom.New(uint64(n), 0.01)就能按期望容量和误判率建表，内部自动把最优bit数和哈希函数数算好。
• 需要持久化到磁盘或者跨进程共享？选willf/bloom，调用Filter.GobEncode()/GobDecode()就行。不过要注意，它的NewWithEstimates()参数顺序容易搞错：先传期望元素数，再传误判率。
• 别自己手写哈希组合——Go标准库的hash/fnv单个哈希不够用，多个哈希还得保证独立性。yourbasic/bloom内部用的是双哈希推导多哈希，经过验证是可靠的。

TestAndAdd()是去重核心，但别在循环里反复New

布隆过滤器实例是有状态的。TestAndAdd()同时完成判断和插入，返回true表示“已存在（或者误判）”，false表示“确定是新的”。这时候才该做后续处理，比如写入数据库或者发消息。

常见错误有几个：

• 每处理一个字符串就new一个过滤器——位图永远为空，所有数据都当成新的，完全失去效果。
• 先用Test()判断，再手动Add()——竞态条件下，两个goroutine可能同时通过Test()，然后都执行Add()，虽然位图只设一次，但业务逻辑已经跑了两次，造成重复。
• 直接把字符串传给TestAndAdd()——它接收的是[]byte，正确的写法是TestAndAdd([]byte(s))；传string会编译不过去。

正确模式是这样的：

// 初始化一次，复用
b := bloom.New(10_000_000, 0.001) // 1000万容量，0.1%误判
for _, s := range hugeStringSlice {
    if !b.TestAndAdd([]byte(s)) {
        // 确实是新字符串，执行去重后逻辑
        processNewString(s)
    }
}

字符串编码和哈希一致性：UTF-8还是raw bytes？

布隆过滤器对输入字节敏感。“café”（含UTF-8编码的é）和“cafe”是完全不同的字节序列。如果数据源本身就是规范的UTF-8，直接[]byte(s)没问题。但如果存在混合编码，或者需要忽略大小写、空白、协议前缀之类的情况，必须在进入布隆过滤器之前统一做预处理。

有几个容易被忽略的点：

• URL去重时，“http://a.com”和“https://a.com”要不要当成不同的？通常需要标准化处理：去掉scheme、trailing slash，以及query参数（或者只保留key）。
• 日志行去重，可能需要trim掉空格，或者把换行符统一成\n。
• 不做预处理就直接塞进去，本该去重的字符串会因格式差异逃过检测。这个时候误判率数字再低也没意义。

布隆过滤器本身不关心语义，它只忠实地对字节数组做位运算。真正的去重效果，一半靠参数配置，一半靠你喂给它的输入是否干净。