Redis Bitmaps硬性上限为2³²位（4294967296位），因offset被定义为uint32_t类型，超出即报错；bitcount的start/end单位是字节而非位，需换算；实际可用空间略小于512MB。
2^32 位，也就是 4294967296 位（约 42.9 亿），这是 Redis Bitmaps 的硬性上限。
这个限制不是由业务逻辑决定的，而是源于 Redis 内部对 offset 参数的校验：所有 bitmap 操作（如 setbit、getbit、bitcount）都要求 offset 必须满足 0 ≤ offset < 2^32。超出即报错 (error) ERR bit offset is not an integer or out of range。
为什么是 2^32？
因为 offset 被定义为 uint32_t 类型 —— 这直接对应 4 字节无符号整数的最大值。即使你用 64 位 Redis 实例，这个限制也不变。
setbit 的 offset 超过 2^32 - 1 会怎样？
立刻失败，不写入，返回明确错误：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
127.0.0.1:6379> setbit user:active 4294967296 1 (error) ERR bit offset is not an integer or out of range
-
4294967295（即2^32 - 1）是合法最大值 -
4294967296及以上全部拒绝 - 注意：这不是内存不足导致的失败，而是参数校验提前拦截
bitcount 的 start/end 参数单位是字节，不是位
这点极易踩坑：
-
bitcount key 0 0统计第 0 个字节（8 位）里有多少个 1 - 想统计前 100 位？得换算：
start = 0,end = 12（因为 100 ÷ 8 = 12.5 → 向上取整到字节边界） - 如果误把位偏移当字节偏移传，比如
bitcount key 0 99，实际会统计前 100 个字节（800 位），结果完全失真
实际可用空间接近但略小于 512MB
理论上 2^32 位 = 536870912 字节 ≈ 512MB，但由于 Redis 字符串底层有少量元数据开销，且最后一个字节可能只用到部分 bit，真实存储占用会略小。不过对绝大多数场景（如签到、用户状态标记），这个容量已足够覆盖几十亿用户级规模。
真正卡住你的往往不是上限本身，而是 offset 编码方式 —— 你得确保用户 ID 或时间戳能安全映射到 [0, 4294967295] 范围内，超出就得做分片或哈希折叠。
