redis服务端需先加载redisbloom模块，通过module list验证存在bf模块；go中用do()调用bf.add/bf.exists，注意参数类型、返回值语义及bf.reserve并发控制，避免误判率失控。
确认 Redis 服务端是否加载了 RedisBloom 模块
直接调用 BF.ADD 报 ERR unknown command `bf.add`，不是 Go 客户端的问题，而是 Redis 实例根本没装模块。必须先验证服务端支持，否则所有后续代码都跑不通。
实操建议：
- 登录 Redis CLI 执行
MODULE LIST，检查输出中是否有name:bf或name:redisbloom - 在 Go 中用
rdb.Do(ctx, "MODULE", "LIST").Val()获取响应，遍历结果判断是否存在bf模块名 - 若不支持，别硬上
BF.*命令——要么推动运维部署 RedisBloom（推荐），要么退到客户端 bitmap 自实现（但会丢失跨实例一致性）
用 go-redis/v9 调用 BF.ADD / BF.EXISTS 的正确姿势
go-redis/v9 不封装布隆命令，但支持 Do() 直接发原始指令，这是当前最轻量、最可控的方式。关键陷阱在于参数类型和语义理解。
实操建议：
-
key和item都必须是string类型，不能传[]byte或结构体；命令参数统一用[]interface{}包裹，例如：rdb.Do(ctx, "BF.ADD", key, item) -
BF.ADD返回整数：1表示新增成功，0表示已存在（不是布尔值） -
BF.EXISTS返回布尔：true表示“可能已存在”，false表示“一定不存在”——这是布隆过滤器的确定性保证，务必按此逻辑分支处理 - 首次
ADD会自动创建 key，使用默认error_rate=0.01和capacity=100；超出容量后误判率会快速上升
BF.RESERVE 必须显式调用且要防并发重复创建
线上服务多实例冷启动时，多个进程同时执行 BF.RESERVE 会导致部分请求失败，报错 ERR not enough memory or key already exists。不能靠“先 EXISTS 再 RESERVE”来规避，因为这不是原子操作。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操建议：
- 用
SET key "init" NX EX 30做分布式锁，成功拿到锁的实例才执行BF.RESERVE，其他实例等待或跳过 - 或者更简单：只在服务初始化阶段（如
main()启动时）由一个固定角色（如 leader 实例）执行BF.RESERVE，其余实例直接使用 -
BF.RESERVE的三个参数顺序是：key、error_rate（如0.001）、capacity（如1000000）；error_rate越低，内存占用越高，需权衡
不要依赖 BF.MADD / BF.MEXISTS 做批量操作
虽然 RedisBloom 提供 BF.MADD 和 BF.MEXISTS，看起来能减少网络往返，但实际在高并发写场景下容易触发 Redis 单线程瓶颈，反而拉高延迟。尤其当批量 size 波动大时，性能不可控。
实操建议：
- 写入走单条
BF.ADD，配合 pipeline 批量提交（注意控制 pipeline 大小，建议 ≤ 100） - 查询优先用
BF.EXISTS单查，除非明确需要一次验多个且数量稳定（如固定 5 个用户 ID），再考虑BF.MEXISTS - 避免在热路径中动态拼接大量
item参数传给M*命令——Go 侧参数展开开销 + Redis 解析开销叠加，容易成为毛刺源
真正难的不是调通命令，而是容量预估和误判率控制。比如 capacity=1000000 但实际存了 200 万，误判率可能从 0.1% 涨到 5% 以上，而这个变化在线上几乎无法实时感知。上线前必须用真实数据集压测验证，而不是只看理论公式。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
