应直接使用 github.com/yourbasic/bloom，因其自动对齐位数组、避免并发竞态、简化容量预估；手写、RedisBloom 封装或自研均易在哈希一致性、内存对齐、并发安全上出错，导致误判率飙升。
直接用 github.com/yourbasic/bloom，别手写、别封装 RedisBloom、别自己算位数组——三者都容易在并发、哈希一致性或容量预估上翻车。
为什么不能手写布隆过滤器
看似几行位运算就能搞定，实则三个硬伤绕不开：
-
hash/fnv不设固定种子，Add和Test用不同实例，结果永远对不上 - 位数组长度没对齐到字节边界（比如该用
(m+7)/8却直接m），bitset[i]访问越界或漏位 - 多个 goroutine 同时
Add同一个 key，竞态修改同一 byte 的不同 bit，|= 1非原子 → 某次置位被覆盖，该 bit 永远为 0，误判率飙升
现象是：明明 Add 过的 key，Test 返回 false；压测时误判率忽高忽低，飘到 5% 以上。这不是参数问题，是底层逻辑崩了。
go-redis/v9 调用 RedisBloom 的坑比收益多
除非你已确认线上 Redis 实例加载了 redisbloom 模块（MODULE LIST 输出含 name:bf），否则所有 BF.ADD 都会报 ERR unknown command `bf.add` ——跟 Go 代码无关，纯服务端配置缺失。
立即学习“go语言免费学习笔记（深入）”；
即便模块就绪，还有几个隐性成本：
-
BF.ADD和BF.EXISTS必须用rdb.Do(ctx, "BF.ADD", key, item)，参数必须全为string，传[]byte会被 JSON 序列化，导致误判 -
BF.RESERVE必须显式调，否则自动建的 key 容量不可控；但并发冷启动时若不加分布式锁，会因key already exists报错失败 - RedisBloom 是服务端状态，无法做本地快速验证；每次改参数都要发命令、等响应、查日志，开发节奏拖慢
怎么选库 + 怎么初始化才不踩坑
日常去重场景（如爬虫、风控白名单）直接上 github.com/yourbasic/bloom：
- 它自动把位数组长度拉齐到 2 的幂次，避免慢的
%运算 -
bloom.New(n, p)中的n是「预估最大插入数」，不是当前数量；填小了后期误判率指数上升（比如预估 10 万却塞进 50 万，fpRate崩到接近 50%） -
p别盲目压低：0.01（1%）是常见平衡点；从0.01 → 0.001，内存几乎翻倍；1e-6级别会让 1 亿条目内存从 ~12MB 涨到 200MB+ - 并发
Add()必须加锁：sync.RWMutex包一层，Add用Lock()，Test用RUnlock()（读可并发）
示例初始化：
<pre class="brush:php;toolbar:false;">var (
mu sync.RWMutex
filter = bloom.New(20_000_000, 0.001) // 爬虫撑 3 天，每天 500 万 URL
)
func Add(key string) {
mu.Lock()
defer mu.Unlock()
filter.Add([]byte(key))
}
func Test(key string) bool {
mu.RLock()
defer mu.RUnlock()
return filter.Test([]byte(key))
}
Test() 返回 true 后必须二次查真实存储
这是最容易被忽略的逻辑责任：Test() 返回 <code>true 只表示「可能存在」，不是「存在」；返回 false 才表示「一定不存在」。
缓存穿透防护典型链路是：
-
Test(key) == false→ 直接放行，不查 Redis/DB -
Test(key) == true→ 必须查 Redis → 存在则返回，不存在则回源 DB 并写入 Redis
跳过这步二次校验，等于把误判当真——风控里可能把新用户当成老用户拦截，爬虫里可能漏掉新发现的 URL。布隆过滤器本身不存数据，也不提供精确判断能力，这点没商量。
