不能直接用EVAL扩容布隆过滤器，因Lua无法动态创建新位图并批量迁移旧偏移位；需采用预分配+双写+离线迁移的两阶段切换方案。
为什么不能直接用 EVAL 扩容布隆过滤器？
Redis 本身不内置布隆过滤器，常见方案是用 SETBIT/GETBIT 模拟位图，再配合 Lua 脚本实现插入、查询。但扩容（比如从 1MB 位图扩到 2MB）需要原子性地：① 创建新位图；② 迁移旧数据；③ 替换键名。这些操作跨多个命令，EVAL 无法在运行时动态创建新 key 并迁移——因为 redis.call('SET', new_key, ...) 只能设字符串值，而位图必须用 SETBIT 逐位写入，但 Lua 中无法批量高效重放所有已置位的偏移量（你根本没存过这些偏移）。
真正可行的扩容路径：预分配 + 分片 + 切换
所谓“原子扩容”，其实是规避在线迁移，改用客户端协调的两阶段切换。核心是让新旧两个布隆过滤器并存，通过 key 命名约定和版本号控制读写路由：
- 用两个 key：
bloom:users:v1和bloom:users:v2，v2 容量更大（比如 bitmap 长度翻倍） - 扩容前先用
SETBIT bloom:users:v2 0 0初始化新位图（确保 key 存在且类型为 string） - 写操作双写：
SETBIT bloom:users:v1 offset 1+SETBIT bloom:users:v2 offset 1（注意：v2 的 hash 函数需适配新容量，比如offset % new_size） - 读操作先查 v2，未命中再查 v1（兼容旧数据），但需在 Lua 中统一封装，避免客户端逻辑分散
关键点：Lua 脚本只负责读写逻辑，不负责“复制旧数据”。历史数据迁移走离线任务（如 SCAN + BITPOS），不在原子上下文中做。
一个安全的双读 Lua 脚本示例
以下脚本用于查询某元素是否存在，自动 fallback 到旧版本：
local key_v2 = KEYS[1]
local key_v1 = KEYS[2]
local offset = tonumber(ARGV[1])
<p>-- 先查新版本
local exists_v2 = redis.call('GETBIT', key_v2, offset)
if exists_v2 == 1 then
return 1
end</p><p>-- 再查旧版本（仅当 v1 存在且类型正确）
local type_v1 = redis.call('TYPE', key_v1)
if type_v1['ok'] == 'string' then
local exists_v1 = redis.call('GETBIT', key_v1, offset % (tonumber(ARGV[2]) or 1048576))
return exists_v1
else
return 0
end调用时传入：redis.eval(script, 2, 'bloom:users:v2', 'bloom:users:v1', offset, new_bitmap_size)。注意 offset % new_bitmap_size 是为了防止旧版 offset 超出新版范围——这要求你在设计 hash 函数时，初始版本就预留可被整除的模数（比如始终用 2 的幂）。
最容易被忽略的三个细节
第一，SETBIT 对不存在的 key 会自动创建，但长度按需扩展；如果扩容后新 key 从未写入，首次 GETBIT 会返回 0，没问题。但如果你依赖 BITCOUNT 统计，就得确保新 key 至少被初始化过一次（哪怕只 SETBIT key 0 0），否则 Redis 会返回 0 而非“key 不存在”错误。
第二，Lua 中无法获取位图当前长度，STRLEN 返回字节长度，但 SETBIT key 1048575 1 可能让实际分配内存远大于 1048576/8 字节（Redis 内部有对齐）。所以不要用 STRLEN 推算容量，显式存一个 bloom:users:v2:size 的元数据 key 更可靠。
第三，双写不是最终态——你需要一个明确的“切换窗口期”，之后停写 v1，并用后台任务清空它。这个窗口期长短取决于业务容忍的误判率上升（v1 停写后，新元素只进 v2，但查询仍 fallback，所以不会漏判；只是 v1 里旧元素若被误删，会导致假阴性）。
