Redis布隆过滤器不支持动态扩容，BF.RESERVE设定的capacity和error_rate不可修改；扩容需手动迁移数据并切换key，参数选错易致内存激增或OOM。
Redis原生命令不支持动态扩容，这是硬限制
Redis自带的BF.ADD和BF.EXISTS操作依赖底层位数组固定长度，一旦用BF.RESERVE（或自动创建）设定了capacity和error_rate，后续无法修改——这不是配置遗漏，而是模块设计决定的。你执行BF.ADD时发现“写入变慢”或“误判率飙升”，大概率不是命令写错了，而是容量早已撑满。
Redisson的tryInit()不是热扩容，只是初始化防护
很多人以为调用RBloomFilter.tryInit(2000, 0.01)能“升级”已有过滤器，其实它只在key不存在时生效；如果myBloomFilter已存在且容量是1000，这个调用直接静默失败。真正要扩容，必须手动迁移：
- 新建一个更大容量的过滤器，比如
redisson.getBloomFilter("myBloomFilter_v2") - 用
bloomFilter.count()确认旧过滤器当前元素量，避免盲目全量重放 - 逐条
add()旧数据到新过滤器（注意：不能用readAll()——布隆过滤器本身不存原始值） - 业务代码切换key名，并删掉旧key（
redisson.getBucket("myBloomFilter").delete()）
参数选错比不扩容更危险：capacity和error_rate的隐性绑定
你以为把capacity从1000改成10000就安全了？错。error_rate实际决定了底层位数组长度m和哈希函数个数k：
— error_rate=0.03时，m≈15×capacity；error_rate=0.001时，m≈24×capacity。
— 容量翻10倍但error_rate不变，位数组内存占用也翻10倍；若同时把error_rate压到0.001，内存可能涨24倍。
实操建议：
- 压测时用
BF.INFO查size（当前位数组字节）和items（插入总数），算填充率：items / capacity - 填充率＞75%就该预警，＞90%误判率会陡增——此时宁可接受0.05的error_rate，也不要硬扛0.01
- 线上环境慎用
error_rate ，它让RedisBloom模块在大容量下更易触发OOM killer
绕过扩容的实用替代方案
真要扛住突发流量又不想改key、不写迁移逻辑？试试这几种轻量级兜底：
- 分片布隆：按ID哈希后路由到
bf_user_0~bf_user_9共10个过滤器，每个容量设为总预估量的1/10 - 双层校验：先过布隆（宽松error_rate=0.1），再对“可能存在”的请求走一次缓存
EXISTS，拦截99%穿透 - 降级开关：监控
BF.INFO的inserted字段突增，自动切到SET临时兜底（代价是内存涨10倍，但保可用）
布隆过滤器的“动态”本质是运维动作，不是API能力。所有想一劳永逸的自动扩容方案，最后都卡在数据一致性上——毕竟它连自己存了啥都不知道。
