必须先确认redis已加载redisbloom模块，否则bf.add等命令报错；验证方式为module list检查name:bf；go中需用do()调用，参数为[]interface{}，返回值需正确处理redis.nil和int64语义；bf.reserve须在启动时单点初始化或加分布式锁；批量操作应分片pipeline而非bf.madd。
直接上结论：Golang + Redis 实现分布式布隆过滤器，**必须先确认 Redis 服务端已加载 RedisBloom 模块**，否则所有 BF.ADD、BF.EXISTS 命令都会报 ERR unknown command `bf.add`——这不是 Go 代码写错了，是 Redis 根本不认这个指令。
怎么验证 Redis 是否支持 BF 命令
跳过这步，后面全白干。线上环境尤其容易忽略，本地 Docker 跑的 Redis 默认也不带模块。
- 登录 Redis CLI 执行
MODULE LIST，检查输出里有没有name:bf或name:redisbloom - Go 里用
rdb.Do(ctx, "MODULE", "LIST").Val()获取响应，遍历结果做字符串匹配（别只看 length > 0） - 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 的真实写法
go-redis/v9 官方不封装 Bloom 命令，Do() 是唯一轻量路径，但参数类型、返回值语义和错误处理稍错就 panic 或逻辑翻车。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
key和item必须是string类型；传[]byte或结构体？直接redis: can't marshal - 命令参数统一用
[]interface{}包裹：rdb.Do(ctx, "BF.ADD", key, item) -
BF.ADD返回int64：1 = 新增成功，0 = 已存在（不是布尔！） -
BF.EXISTS返回int64：1 = “可能已存在”，0 = “一定不存在”；若key未初始化，它返回redis.Nil，直接调.Bool()会 panic - 正确判空写法：
if errors.Is(err, redis.Nil) { return false }，再对val.(int64)做判断
为什么 BF.RESERVE 不能“先查再建”，以及怎么安全初始化
默认 BF.ADD 会自动创建 filter，但容量固定为 100、误判率 0.01，生产环境根本不可控。显式 BF.RESERVE 是必须的，但并发调用会撞出 ERR not enough memory or key already exists。
- 别写
EXISTS → RESERVE两步——中间有竞态窗口，多个实例几乎必然失败 - 最简方案：只在服务启动时（如
main()）由单个实例执行rdb.Do(ctx, "BF.RESERVE", key, 0.001, 1000000)，其余实例跳过 - 更稳方案：用
SET lock:key "init" NX EX 30做分布式锁，抢到锁的实例才调BF.RESERVE，失败者等待后重试 -
BF.RESERVE三个参数顺序固定：key、error_rate（如0.001）、capacity（如1000000）；error_rate越低，内存占用越高，得按实际元素量级算
BF.MADD / BF.MEXISTS 看似省事，为什么高并发下反而更慢
批量接口听起来高效，但在 Redis 单线程模型下，大 payload 会卡住整个事件循环，延迟飙升，尤其当一次塞几百个 item 时。
-
BF.MADD和BF.MEXISTS返回的是[]int64数组，每个位置对应一个 item 的结果（1/0），但网络往返没减少，反而增大单次请求体积 - 实测中，100 个 item 分 10 次
BF.ADD（pipeline 合并），比 1 次BF.MADD平均延迟低 30%~50% - 真要批量，建议分片：每批 ≤ 20 个 item，用 pipeline 封装多条
BF.ADD，既保原子性又控延迟 - 注意：
BF.MADD遇到某个 item 写失败（比如 key 类型冲突），整批会中断，错误处理比单条难
真正容易被忽略的点是：误判率不是配置完就一劳永逸的。当实际写入量持续超过 BF.RESERVE 时指定的 capacity，误判率会指数级上升——监控 BF.INFO 返回的 size 和 items 比值，超 0.8 就该触发重建流程。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
