bitfield是redis中唯一能安全、原子地批量操作位图的命令，它避免了多次setbit的解析开销、内存碎片和竞态问题，且支持u1类型精准写入单bit；而pipeline虽减少网络往返，却不保证原子性且扩容效率低。
BITFIELD 是 Redis 中唯一能安全、原子地批量操作位图的命令，用它替代多个 SETBIT 或管道（pipeline）是性能优化的关键。
为什么不能用 pipeline 塞一堆 SETBIT
看起来 pipeline 能减少网络往返，但每个 SETBIT 仍要单独解析、检查 offset、触发内存扩容逻辑。尤其当 offset 很大时，多次 realloc 容易造成内存碎片，实际吞吐反而比 BITFIELD 低。更关键的是：pipeline 不保证原子性——中间某条失败，其余已执行的无法回滚。
-
SETBIT每次只写 1 bit，命令开销占比高；BITFIELD单次请求复用同一段内存，避免重复寻址 - 遇到未分配的大 offset，
SETBIT每次都可能触发 chunk 扩容；BITFIELD在内部统一处理，仅扩容一次 - 并发场景下，多个
SETBIT之间存在竞态窗口；BITFIELD整个请求是原子的
BITFIELD 的 u1 SET 是最稳妥的位状态写法
想把第 10086 位设为 1，别用 INCRBY u1 10086 1——u1 只能存 0 或 1，加 1 后溢出归零，结果反而是 0。正确做法是明确覆盖：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
BITFIELD mybitmap SET u1 10086 1 SET u1 20240 0 SET u1 9527 1
- 必须用
u1类型，i1不存在，i8或u8会读写整个字节，破坏其他位 -
SET参数顺序是type offset value，写成SET u1 1 0表示“把 offset=1 的位设为 0”，顺序颠倒就写错位置 - 所有
SET u1操作共享 key，不能跨 key；要更新多个 bitmap，得发多个BITFIELD命令
GET + SET 链式操作要注意返回值结构
需要“先读再按条件写”时，可以链式写：BITFIELD mykey GET u1 123 SET u1 123 1。但返回值不是布尔标志，而是数组：
[0, 0]
第一个元素是 GET u1 123 的结果（原值），第二个是 SET u1 123 1 的**旧值**（不是新值，也不是成功与否的标识）。
- 若 offset 超出范围或为负，对应位置返回
(nil)，不是报错，客户端必须显式判断 null - 在 Lua 脚本里，返回的是 Redis table，需用
table[1]、table[2]逐项取，不能直接解包 - 不要把
SET的返回值当“写入是否成功”，它只是上一个值；是否生效，取决于命令是否执行完成（无异常即生效）
大 offset 下的内存占用容易被低估
BITFIELD 遇到超出现有长度的 offset 会自动扩容，但不是按 bit 精确分配，而是按 chunk（通常是 64 字节 = 512 bit）对齐。比如只写 offset=5000，Redis 实际会分配到 ≥5000 的最小 chunk 边界（可能是 5120），空闲位全补 0。
- 如果业务 ID 稀疏（如用户 ID 跨度大但活跃量少），用 Bitmap 反而浪费内存，此时应考虑布隆过滤器或分片 key
- 用
STRLEN查看底层字符串长度，可验证实际分配大小；MEMORY USAGE返回的是总内存（含 SDS 开销） - 高频小写场景下，
BITFIELD的批量能力收益明显；但单次只改 1–2 位时，SETBIT更直观，不必强行套用
