BITOP AND 不能直接算「今天登录且本月付费」用户数，因其要求两bitmap长度一致、索引严格对齐同一用户ID，而不同时间粒度key（如user:login:20240615与user:pay:202406）长度和offset常不一致，直接运算会截断或补零致结果错乱。
BITOP AND 为什么不能直接算「今天登录且本月付费」的用户数
因为 BITOP AND 是位级运算，输入的两个 bitmap 必须长度一致、索引对齐——而「今天登录」和「本月付费」通常存的是不同时间粒度的 key，比如 user:login:20240615（长度 ≈ 用户 ID 最大值）和 user:pay:202406（长度可能更大，因含更多历史 ID），直接 BITOP AND 会截断或补零，结果错乱。
真正能交集的前提是：所有 bitmap 的 bit 位置必须代表同一组用户，且索引严格对应同一用户 ID。常见错误是拿不同 offset 基准的 bitmap 做 AND，比如一个按全局 UID 存，另一个按当天注册用户重编号，结果全为 0。
- 确保所有参与
BITOP AND的 key 都基于相同用户池构建，推荐统一用「全站用户 ID 连续编号」（如 1~1000 万）作为 bit 索引 - 避免用日期字符串拼接生成 key 后直接 AND；先用
BITCOUNT单独验证各 key 的基数是否合理，再操作 - 如果用户 ID 稀疏（比如最大 ID 是 1 亿但只用了 10 万个），用
SETBIT写入时别盲目扩长——Redis 会分配完整内存，浪费严重；可考虑用布隆过滤器预筛或分段 bitmap
如何安全地构建「登录+付费+地域」三维度交集
不能把三个 bitmap 一次 BITOP AND，因为 Redis 的 BITOP AND destkey srckey1 srckey2 srckey3 是两两左结合（(A AND B) AND C），中间结果若为空则后续全空；更关键的是，三者 bit 长度不一致时，第二步的 AND 会以第一步结果长度为准截断第三个 key，丢数据。
正确做法是分步对齐 + 显式控制长度：
- 先用
BITCOUNT查出三个 key 的实际有效长度（即最高置 1 位的位置），取最小值min_len - 用
GETRANGE分别截取每个 bitmap 的前min_len字节（注意：bit 索引从 0 开始，字节偏移 = floor(bit_index / 8)，需向上取整） - 将截取后的二进制数据分别写入临时 key（如
tmp:a,tmp:b,tmp:c），再用BITOP AND dest tmp:a tmp:b，最后BITOP AND dest dest tmp:c - 或者更稳妥：用 Lua 脚本在服务端完成对齐与 AND，避免多次网络往返和中间状态污染
BITOP AND 的性能陷阱：为什么线上突然变慢
BITOP AND 是 O(N) 时间复杂度，N 是最长输入 key 的字节数。表面看只是“与运算”，但当 bitmap 达到 10MB（对应约 8000 万用户），单次操作可能耗时 20ms+，阻塞主线程——尤其在高并发场景下，多个 BITOP 排队会让 Redis latency 报警。
- 不要在请求链路中实时执行多 key
BITOP AND；应提前计算好常用组合，存为新 key（如user:active:login_pay_june），用空间换时间 - 监控
redis-cli --stat中的cmdstat_bitop耗时，若 P99 > 5ms，说明该模式已到瓶颈 - 替代方案：用 HyperLogLog 做近似交集（
PFCOUNT+PFMERGE不适用，但可结合PFADD分维度写入后用客户端做集合交集）；或迁移到 RedisBloom 的BF.MEXISTS多 key 查询
上线前必须验证的三个边界情况
Bitmap 交集逻辑看似简单，但生产环境常因边界值崩掉：
- 某个维度无数据（如当天没付费用户）：对应 key 不存在或全 0，
BITOP AND结果为全 0，但业务可能误判为“有交集但人数为 0”，需在代码里显式检查EXISTS key和BITCOUNT key - 用户 ID 超过 2^32（42 亿）：Redis bitmap 理论支持，但部分客户端（如 jedis）默认用 int 解析 offset，会溢出；务必确认 client 是否支持 long 类型 bit 索引
- 集群模式下跨 slot：如果三个 key 不在同一个 hash slot，
BITOP会报CROSSSLOT错误；解决方案是用{tag}保证 key 落在同一 slot，例如user:{12345}:login、user:{12345}:pay
交集结果本身不难算，难的是让每一步的 bit 对齐不漂移、长度不越界、集群不报错——这些细节漏掉一个，凌晨三点的告警就来了。
