SETBIT不能存储PNG等二进制文件，因其仅支持单比特写入，需8192次命令存1KB图片，且无法精准控制字节内8位值；它专用于布尔标记、布隆过滤器、签到统计等位级操作场景。
Redis 的 String 类型原生支持二进制数据存储，不需要编码转换；但 SETBIT 和 GETBIT 不是用来“存整个二进制对象”的，而是操作字符串底层的位数组——它们适合做布尔标记、布隆过滤器、用户签到统计等场景，不是替代 SET/GET 存图片或序列化数据的方案。
为什么不能用 SETBIT 存一个 PNG 文件
因为 SETBIT 每次只能写 0 或 1，而 PNG 是字节流（每个字节 8 位），要存 1KB 图片就得发 8192 次命令，网络开销和延迟爆炸。更关键的是：SETBIT 写入时会自动零扩展，但扩展出的中间字节全是 0，无法精准控制每个字节的全部 8 位值 —— 你没法用它还原原始字节序列。
-
SET key "\x89PNG"直接存二进制头，GET取出就是原样字节 -
SETBIT key 0 1只改第 0 位（最高位），不影响其他 7 位；若该位置原为\x00，改完是\x80，不是你想写的\x89 - 想用位操作拼出
\x89（二进制10001001），得调 8 次SETBIT，且 offset 要算对：从高位开始，offset 0=1、offset 1=0…offset 7=1 —— 容易错位
SETBIT 和 GETBIT 真实适用场景
它们的设计目标是高效存取海量稀疏布尔状态，比如：每日用户签到（1 亿用户 → 12.5MB 内存）、活跃设备标记、权限开关位图。这时你关心的不是“某个字节是多少”，而是“第 N 个 bit 是不是 1”。
- offset 从 0 开始，按位计数，不是按字节；
GETBIT key 100查的是整个字符串的第 101 位（从左往右） - 字符串自动扩容：如果当前值只有 1 字节（8 位），
SETBIT key 100 1会把前面 0–99 位全补 0，再设第 100 位为 1 - 读写原子：单个
SETBIT是原子的，但批量位操作要用BITFIELD（Redis 3.2+），避免多次往返 - 注意字节序：Redis 位顺序是 big-endian（高位在前），
GETBIT key 0拿到的是第一个字节的最高位，不是最低位
SETBIT 常见踩坑点
实际用的时候，最容易栽在 offset 计算和边界行为上。
- 误把 offset 当字节索引：
SETBIT key 10 1不是“第 10 个字节”，而是“整个位数组的第 10 位”，它可能落在第 2 个字节（index=1）的第 2 位（bit index=2） - 清零操作必须显式写 0：
SETBIT key 5 0才能确保第 5 位为 0；不操作 ≠ 0，未初始化的位默认是 0，但依赖这个逻辑容易混淆 - 性能陷阱：高频小 offset 写入（如
SETBIT key 0 1循环 10 万次）比一次写大 offset（SETBIT key 999999 1）慢得多 —— 因为每次都要加载并修改不同内存页 -
GETBIT对不存在的 key 返回 0，不是 nil；这和GET行为不一致，代码里容易漏判
什么时候该用 SET，什么时候用 SETBIT
核心判断标准就一条：你要存的是“完整二进制 blob”，还是“一堆独立的 yes/no 标记”。
- 存图片、音视频、Protobuf 序列化数据 → 无条件用
SET/GET，二进制安全，直接传 bytes - 统计某天多少用户登录过（用户 ID 作为 offset）→
SETBIT+BITCOUNT，空间省 8 倍 - 需要查“第一个没签到的用户 ID” →
BITPOS key 0，比遍历快几个数量级 - 要存带符号整数或多位字段（如 5 位等级 + 3 位状态）→ 改用
BITFIELD，SETBIT压根不支持
位操作真正难的不是语法，是把业务问题映射到位索引上——比如用户 ID 是 10 位十进制数，直接当 offset 用没问题；但如果是 UUID 字符串，就得先哈希再 mod 位图长度，否则稀疏度爆炸。这点一旦设计错，后面扩容和查询都头疼。
