BITOP适合状态交并差但非状态机引擎，仅执行原子位运算（AND/OR/XOR/NOT）输出新位图；状态流转需SETBIT+客户端逻辑+BITOP聚合配合，不可单靠BITOP实现条件迁移或过程校验。
BITOP 适合做状态交并差，但别直接拿它当状态机引擎
BITOP 不是状态机的替代品，它只负责对多个位图做原子级逻辑运算（AND/OR/XOR/NOT），输出新位图。真要实现「状态流转」，得靠 SETBIT + 客户端逻辑控制 + BITOP 聚合三者配合。比如用户权限变更、设备在线/离线/故障三态标记，不能只靠一次 BITOP OR 就完成状态迁移——它不记录变化过程，也不校验前置条件。
常见错误现象：BITOP AND user:status:final user:online user:authed user:paid 执行后发现结果为空，不是逻辑错了，而是三个源 key 中任意一个在某 bit 位为 0，结果就为 0；而你真正想表达的可能是「只要满足任意两个条件就允许访问」，这已经超出 BITOP 单次运算能力范围。
- BITOP 的每个操作都是无状态的：输入确定，输出确定，不保留中间状态或上下文
- AND/OR/XOR 要求所有参与 key 的 bit 偏移对齐才有意义；若
user:online最大 offset 是 1000，user:authed是 5000000，则 AND 结果长度取 5000000/8 字节，前 1000 位之外全是 0，容易误判 - NOT 只支持单 key，且会按该 key 当前最大偏移补零，可能导致高位稀疏时内存暴涨
用 BITOP 实现「多条件组合状态」的正确姿势
把不同维度的状态拆成独立位图，再用 BITOP 组装出复合判定结果，比在单个 key 里用多 bit 编码状态更清晰、更易维护。例如设备管理场景：
-
device:online:{date}：第 i 位 = 1 表示设备 i 当日在线 -
device:alarm:{date}：第 i 位 = 1 表示设备 i 当日触发告警 -
device:maintained:{date}：第 i 位 = 1 表示设备 i 当日被人工维护过
要统计「当日在线且未告警」的设备数，执行：
BITOP AND device:healthy:20260527 device:online:20260527 device:alarm:20260527 BITCOUNT device:healthy:20260527
注意：device:alarm:20260527 里存的是「告警发生」，所以先用 BITOP NOT 取反再 AND 更合理：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
BITOP NOT device:healthy:20260527 device:alarm:20260527 BITOP AND device:healthy:20260527 device:online:20260527 device:healthy:20260527
这样避免了手动构造全 1 位图的麻烦，也规避了 NOT 对高位稀疏 key 的风险（只要 device:alarm:20260527 本身不稀疏就行）。
BITOP 在高并发下卡住的真实原因和绕过方法
BITOP 卡住不是因为并发量大，而是因为某个参与运算的 key 实际只设置了极少数高位 bit（比如 SETBIT user:flag 99999999 1），导致 Redis 必须分配约 12.5MB 内存（99999999 ÷ 8 ÷ 1024 ÷ 1024）来加载从 0 到该 offset 的完整字节数组——哪怕其他 99.99% 的字节都是 0。
实测：10 个 100MB 的密集 bitmap 做 BITOP OR，耗时约 300ms；但混入一个只设了第 1 亿 bit 的 key，峰值内存飙升至 12GB，超时失败。
- 检查高位稀疏 key：
STRLEN key返回字节数，乘以 8 就是当前有效 bit 上限；若远小于业务预期最大 offset，说明有稀疏写入 - 禁止人工用
SETBIT写超大 offset；用户 ID 映射到 bit 位必须做哈希或取模压缩（如user_id % 10000000） - 替代方案：不用 BITOP 全量计算，改用
BITPOS key 1 start end分段扫描各 key 的置 1 位置，客户端求交集。内存恒定，但网络请求变多，适合对延迟不敏感、对 OOM 零容忍的场景
为什么 BITOP 后还要配 BITCOUNT 或 BITPOS？
BITOP 只产生新位图，不返回任何统计信息。你无法知道 BITOP AND dest k1 k2 后 dest 里到底有多少个 1，必须显式调用 BITCOUNT dest。同理，若只想知道第一个满足「在线且已认证」的用户 ID，得用 BITPOS dest 1，而不是假设 BITOP 自带定位能力。
容易被忽略的关键点：
-
BITCOUNT默认按字节统计，若你用unit: 'BIT'指定了位范围，务必确认start和end是位偏移而非字节偏移，否则结果错位 -
BITPOS查value 1返回首个 1 的位置，查value 0返回首个 0 的位置；但若整个范围全是 1，它返回 -1 —— 这不是错误，是设计如此，需在代码里处理 - BITOP 的
destkey若已存在，会被覆盖；若希望保留历史结果，得用唯一命名（如加时间戳或 hash），否则并发写可能互相擦除
