BITFIELD操作的是“字段”，SETBIT/GETBIT操作的是“单个位”；前者支持u8、i16等位宽读写整数，后者仅返回0或1。
BITFIELD 不是用来替代 Hash 或 String 的，而是当你有一堆小整数字段、且字段数量固定、取值范围明确时，它能把几十字节压缩到几个字节，同时保持原子性读写。
BITFIELD 和 SETBIT/GETBIT 的根本区别在哪
SETBIT 只能操作单个 bit，返回值永远是 0 或 1；BITFIELD 操作的是“字段”，比如 u8（无符号 8 位）、i16（有符号 16 位），一次读写直接返回 0~255 或 -32768~32767 这样的整数。它底层仍基于字符串，但把字符串当连续比特流来切片使用。
常见错误现象：
- 用
SETBIT key 10 1想存一个等级值 12，结果只写了第 10 位为 1，其他位全 0，读出来还是 1 —— 因为它不是按字段存的 - 误以为
BITFIELD key GET u8 0是“从第 0 字节读 1 字节”，其实它是“从第 0 位开始，取连续 8 位”，而 Redis 字符串是大端序，第 0 位是最高有效位
关键参数差异：
-
u8：无符号 8 位，范围 0~255，适合状态码、等级、小计数器 -
i8：有符号 8 位，范围 -128~127，适合带方向的差值（如积分变动） -
offset单位是 bit，不是 byte —— 写u8字段时，偏移量每 +8 才挪到下一个字节
怎么设计位宽和偏移才能不踩内存错位
位宽必须严格匹配业务取值范围，否则溢出或浪费。比如用户等级最大到 99，用 u8（0~255）绰绰有余；但若存“是否 VIP”+“是否新手”+“是否实名”三个布尔值，用三个 u1 字段比一个 u8 更省？错 —— Redis 最小分配单位是字节，u1 和 u8 在同一个字节里都只占 1 字节空间，但 u1 偏移要精确到 bit 级，易出错。
推荐做法：
- 把逻辑上一组的小字段打包进同一字节或双字节，例如：前 3 位存状态标志（VIP/新手/实名），后 5 位存等级（0~31），合起来用一个
u8 - 不同字段之间留至少 1 bit 间隔，避免因偏移计算偏差导致字段覆盖（尤其多人协作维护 offset 时）
- 不要跨字节对齐强求“紧凑”，比如用
u3+u5刚好 1 字节，但后续加字段就得重算所有 offset，不如统一用u8起始偏移按 8 的倍数递增
性能影响：字段越窄，单次操作 CPU 开销略低，但 offset 计算误差风险上升；字段过宽（如盲目用 u64）会浪费空间，且在 32 位 Redis 实例上可能触发兼容性问题。
INCRBY 配合 OVERFLOW 实现安全封顶自增
BITFIELD 的 INCRBY 是原子的，比先 GET 再 SET 安全得多，特别适合并发场景下的计数器。但它默认溢出行为是 WRAP（回绕），比如 u8 字段当前是 255，INCRBY u8 0 1 会变成 0 —— 这通常不是你想要的。
必须显式指定 OVERFLOW 策略：
-
OVERFLOW SAT：饱和截断，u8到 255 后再增仍为 255，i8到 127 后再增仍为 127 -
OVERFLOW FAIL：溢出时整个命令返回 nil，需要客户端重试或降级处理 -
OVERFLOW WRAP：仅适用于循环计数场景（如日志序列号），日常慎用
示例：给用户积分字段（u16，偏移 16）加 10，封顶 65535：
BITFIELD user:1001 INCRBY u16 16 10 OVERFLOW SAT
注意：OVERFLOW 必须紧跟在对应子命令之后，不能全局设置；多个子命令可混合使用不同策略。
为什么 BITFIELD 容易被当成“高级 SETBIT”而用错
最常被忽略的是“位序”和“类型语义”的绑定关系：Redis 字符串是大端序，u8 字段从偏移 0 开始读，拿到的就是第一个字节的完整值；但如果你写 i8，同样偏移 0，读出来的可能是负数（因为最高位被解释为符号位）。这跟 C 语言位域中 int a:8 和 unsigned int a:8 的行为完全一致。
另一个隐蔽坑点是客户端兼容性：部分老版本 Jedis 或 redis-py 对多子命令返回数组的解析不健壮，尤其混用 GET/SET/INCRBY 时，可能丢数据或类型错乱。建议生产环境统一用 Redis 6.0+ + 官方推荐客户端，并对返回值做长度校验。
复杂点在于：它不像 Hash 那样天然支持字段名，所有字段靠 offset 和 type 约定，一旦 offset 算错或 type 写反（比如该用 u8 写成 i8），读出来的值就不可逆地错乱，且难以 debug —— 因为底层就是一串看不出含义的二进制。
