必须确认Redis已加载RedisBloom模块，否则BF.ADD等命令报ERR unknown command；需用MODULE LIST验证，Go中用Do("MODULE","LIST")检查，Docker推荐redislabs/redismod镜像。
直接用 go-redis/v9 的 Do() 调用 BF.ADD 和 BF.EXISTS 是最稳妥的路径，但前提是 Redis 服务端已加载 redisbloom 模块——没这一步，所有命令都会报 ERR unknown command `bf.add`，跟 Go 代码无关。
怎么确认 Redis 已启用 redisbloom 模块
跳过这步，后续所有操作都是空转。线上环境十有八九没开，本地 Docker 也常默认不带。
- 登录 Redis CLI 执行
MODULE LIST，检查输出中是否有name:bf或name:redisbloom - 在 Go 中用
rdb.Do(ctx, "MODULE", "LIST").Val()获取响应，遍历结果找"bf"字符串 - Docker 快速验证：
docker run -p 6379:6379 redislabs/redismod（预装 RedisBloom v2.6+） - 自己编译部署时，启动日志必须出现
Module 'bf' loaded from，且redis-server --version输出含redis-bloom
go-redis/v9 调用 BF.ADD 和 BF.EXISTS 的硬性要求
官方客户端不封装 Bloom 命令，Do() 是唯一入口，但参数类型和返回值处理错一点就 panic 或逻辑翻车。
-
key和item都必须是string类型，传[]byte或结构体会被序列化成 JSON，导致误判 - 命令参数统一用
[]interface{}包裹，例如：rdb.Do(ctx, "BF.ADD", key, item) -
BF.ADD返回int64：1 表示新增，0 表示已存在（不是布尔值） -
BF.EXISTS返回true表示“可能已存在”，false表示“一定不存在”——这是布隆过滤器的确定性保证，不能反着用 -
BF.EXISTS在 key 不存在时返回redis.Nil，直接调.Bool()会 panic，必须先.Result()再类型断言
为什么 BF.RESERVE 必须显式调用且要防并发
默认 BF.ADD 会自动建 key，但容量（100）和误判率（0.01）不可控；超出容量后误判率飙升，生产环境必须显式控制精度。
立即学习“go语言免费学习笔记（深入）”；
-
BF.RESERVE参数顺序是key、error_rate、capacity，例如：rdb.Do(ctx, "BF.RESERVE", key, 0.001, 1000000) -
BF.RESERVE在 key 已存在时会报错：ERR not enough memory or key already exists - 多个服务实例冷启动时可能同时尝试创建，需加分布式锁或用
SETNX+ TTL 做幂等保护，否则部分请求失败 - 不要依赖首次
BF.ADD自动建 key，它用的默认参数在高吞吐场景下很快失效
真正难的不是写那几行 Do() 调用，而是把 BF.RESERVE 的精度参数和业务实际数据量对齐，并在多实例部署下安全落地——误判率设低一档，内存翻倍；容量估小一点，上线三天误判率就从 0.1% 涨到 5%。这些没法靠代码自动修复，得靠监控和定期校准。
