当 BF.INFO 显示 items/capacity > 0.8 时必须重建布隆过滤器，因其误判率已失控；重建需 BF.RESERVE 新实例、按峰值×1.3～1.5设 capacity、BF.MADD 迁移，并配合监控与验证闭环。
BF.INFO 显示 items/capacity > 0.8 就该重建了
布隆过滤器的误判率不是运行时动态调节的，它在 BF.RESERVE 创建那一刻就由 capacity 和 error_rate 共同锁定了位数组大小 m 和哈希函数数 k。一旦实际插入元素数 items 接近或超过预设 capacity，哈希冲突概率急剧上升，误判率会从理论值（比如 0.01）跳到 5% 甚至更高。
验证是否过载只需一条命令：BF.INFO key，看返回中 items 与 capacity 的比值：
- 比值 ≤ 0.7：当前较安全，可继续使用
- 比值 ∈ (0.7, 0.8]：开始预警，建议准备重建
- 比值 > 0.8：已明显过载，误判率失控，必须重建
重建不是“调参”，而是重新 BF.RESERVE + 迁移数据
Redis 布隆过滤器不支持修改已有实例的 capacity 或 k。所谓“重建”，本质是创建一个新 filter，再把旧数据灌进去。关键点在于：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 新
capacity要按真实峰值 × 1.3～1.5 设，不能只补一点；例如历史最多存过 80 万，新容量至少设 120 万 - 新
error_rate可保持不变（如仍用 0.01），它只影响初始化计算，不决定运行时行为 - 迁移必须用
BF.MADD批量导入，别用循环BF.ADD—— 后者在扩容临界点可能漏刷部分哈希位，导致重建后误判率反而更高 - 线上服务需双写过渡：先写新 filter，再读新 filter 判断，确认稳定后再停旧 filter
为什么不能依赖自动 expand？
BF.ADD 或 BF.MADD 确实可能触发自动扩容（当 items ≥ capacity 时），但 RedisBloom 的 expand 机制有硬伤：
- 它不是重建全新位图，而是尝试复用旧结构 + 追加扩展段，旧位图的哈希分布已劣化，扩展段无法修复整体冲突
- expand 过程中若发生并发写入，部分元素可能仅写入旧段或仅写入新段，造成状态不一致
- 扩容后的
k不变，但位图总长m增长不均匀，理论误判率公式失效，实际表现不可控 - 你无法通过
BF.INFO准确获知 expand 是否成功、扩了多少——它只显示当前capacity，不暴露内部分段细节
重建最容易被忽略的细节：冷热数据分离与监控闭环
重建不是一锤子买卖。真正压住误判率，靠的是把重建动作嵌入可观测流程：
- 不要等报警才重建：在定时任务里每小时跑一次
BF.INFO，对items/capacity > 0.75的 key 自动触发告警，并记录趋势 - 区分冷热数据：长期不更新的 filter（如用户黑名单）可设极高冗余（×2.0），高频写入的（如实时设备 ID 去重）必须预留更宽松 buffer（×1.5 以上）
- 重建后必须验证：用一批已知“不存在”的测试样本跑
BF.EXISTS，统计实际误判率，不能只信理论值 - 注意客户端缓存：如果业务层缓存了 filter 判断结果，重建后要清掉相关缓存，否则旧判断逻辑还在生效
误判率失控从来不是突然发生的，而是 capacity 估算偏差、缺乏 BF.INFO 监控、以及把 expand 当万能解这三件事叠在一起的结果。重建本身很简单，难的是让重建成为可预期、可验证、可自动化的例行操作。
