Redis Bitmap 仅支持0/1二值状态，因单bit物理限制无法存储多状态；强行模拟会导致空间浪费、逻辑错误或运维复杂度飙升，应按场景选用Hash、BITOP组合或多key分片等更适配方案。
Redis Bitmap 本身不支持多状态位记录——它只能存 0 或 1，这是底层设计决定的，强行“模拟多状态”会破坏空间效率、引入逻辑歧义，且极易出错。
为什么不能直接用 Bitmap 存多状态（比如 0/1/2/3）
Bitmap 的每个 offset 对应一个 bit，而一个 bit 只能表示两种值：0 或 1。你无法在一个 bit 里塞进 2 或 3 —— 这不是 Redis 的限制，是二进制本身的物理约束。
常见错误尝试包括：
- 用多个 Bitmap 拼凑（如
user:status:1001:type1、user:status:1001:type2），但 key 膨胀严重，运维和统计成本陡增； - 把 offset 当成“用户 ID”，value 当成“状态码”，结果
SETBIT key 1001 3实际写入的是 bit 值 1（因为 Redis 会自动转为布尔值），3 被截断为 1； - 试图用
BITFIELD的u2（2-bit 无符号整数）存状态，但必须严格对齐 offset × 字段宽度，稍有错位就全盘错乱，且BITFIELD不支持原子范围写入，高并发下易覆盖。
真正可行的替代方案：按场景选对工具
当业务需要“多状态”（如：未激活 / 试用中 / 正式付费 / 已降级 / 已注销），优先考虑以下组合，而非硬套 Bitmap：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用 Bitmap 只存最核心的「二值快查字段」：例如
user:active:202609（本月是否产生过有效行为）、user:pay:202609（本月是否完成过支付）——这些用于秒级筛选、实时看板； - 多状态主数据存在 Hash 或 JSON（Redis 7.0+）里：
HSET user:profile:1001 status "trial" last_update "1725380400"，保证语义清晰、可扩展； - 需要高效交集/并集统计？把多状态映射为多个 Bitmap 的 tag 组合：比如状态为
trial的用户写入status:trial:202609，状态为paid的写入status:paid:202609，再用BITOP AND找“试用转付费”的用户集合； - 若状态变更极频繁且需事务性更新，改用 Stream + Consumer Group 做状态事件流，Bitmap 仅作最终聚合快照。
BITFIELD 确实能存多值，但只适合极窄场景
BITFIELD 允许在同一个 key 的不同 bit 区域存多个小整数（如 u2、i4），但它不是“多状态 Bitmap”的银弹：
- 必须预设字段宽度和起始 offset，扩容困难（比如从
u2升级到u3需全量迁移）； -
GET和SET必须精确指定 offset × width，错一位，后续所有字段全偏移； - 无法用
BITCOUNT或BITPOS直接统计某类状态，得靠客户端遍历解析，失去 Bitmap 的原生性能优势； - 生产环境出过因
BITFIELD写入越界导致 key 被静默截断的 case，debug 成本极高。
目前只推荐用于：设备固件版本号（u8.u8.u8）、协议状态字（固定 16-bit 标志位）、或硬件传感器原始采样值压缩存储——且必须配套单元测试验证 offset 计算逻辑。
真正容易被忽略的点是：Bitmap 的价值不在“能存什么”，而在“能多快、多省地回答某类问题”。一旦你开始纠结“怎么让一个 bit 表示三种状态”，说明已经偏离了它的设计原点。该用 Hash 就用 Hash，该分片就分片，别为了省几 KB 内存，把系统变成只有自己能维护的黑盒。
