Redis需手动加载RedisBloom模块才能使用BF.ADD等命令；BF.EXISTS返回false可确定不存在，true仅为可能存在的概率判断，不可作为最终依据。
RedisBloom 模块没装好，BF.ADD 直接报错 “unknown command”
Redis 默认不带布隆过滤器命令，必须单独加载 RedisBloom 模块（v2.4+ 支持原生命令，但得手动载入）。本地开发用 Docker 最省事：
docker run -p 6379:6379 redislabs/redismod。如果自己编译 Redis，得确认
redis-server --loadmodule /path/to/redisbloom.so 成功启动，且日志里有 Module 'bf' loaded from。用 MODULE LIST 命令查一下，输出里没有 bf 就说明模块根本没挂上。
Go 客户端调用 BF.EXISTS 返回 false，但数据其实存在
这不是 Go 的问题，是布隆过滤器本身的误判特性在起作用：它只保证“不存在”一定准确，“存在”可能误判（假阳性），但绝不会漏判（无假阴性）。所以 BF.EXISTS key item 返回 false，你能 100% 确定 item 没见过；返回 true，只是“很可能见过”，还得去查真实数据源（比如 DB）确认。
- 别拿
BF.EXISTS当最终判断依据，它只适合前置拦截——比如防缓存穿透，先过布隆再查 Redis 缓存，最后查 DB - 初始化时用
BF.RESERVE控制精度：BF.RESERVE key 0.01 100000表示期望误判率 1%，容量 10 万；误判率越低、内存占用越高 - Go 里用
github.com/go-redis/redis/v8时，直接走client.Do(ctx, "BF.EXISTS", key, item).Bool()，别用封装好的高级方法——很多客户端没适配 Bloom 命令
并发写入时 BF.ADD 和 BF.MADD 性能差很多
BF.ADD 是单条命令，每次网络往返开销固定；BF.MADD 一次塞 N 个元素，吞吐量能翻几倍。但要注意两点：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
BF.MADD是原子的，整批要么全成功、要么全失败（实际极少失败），适合批量导入场景；而循环调BF.ADD在中间出错时状态难回滚 - 别盲目堆数量——实测超过 500 个元素后，单次
BF.MADD延迟上升明显，建议按 100–300 分批 - 如果业务要求强实时（比如注册即刻生效），用
BF.ADD更稳妥；后台异步构建过滤器，就用BF.MADD+ pipeline
Go 里没处理 redis.Nil，BF.EXISTS 报 panic
当 key 不存在时，BF.EXISTS 不返回错误，而是返回 redis.Nil（类型为 *redis.StatusError）。Go 客户端默认会把它转成 error，但你直接 .Bool() 会 panic：“interface conversion: interface {} is nil”。必须显式检查：
立即学习“go语言免费学习笔记（深入）”；
val, err := client.Do(ctx, "BF.EXISTS", key, item).Result()
if err == redis.Nil {
// key 不存在，相当于“肯定没加过”，可安全返回 false
return false, nil
}
if err != nil {
return false, err
}
exists, ok := val.(int64)
return exists == 1, nil
更稳的做法是封装一层，把 redis.Nil 归一化为逻辑上的 false，避免每个调用点都重复判空。
BF.INFO 里的 size 和 items，一旦接近容量上限，就得重建或扩容——否则误判率会远超预期。 
