因为SETBIT操作的是位数组的下标offset而非UID本身，直接用UID会导致内存爆炸和稀疏空洞；必须通过哈希或取模映射到合理范围，且需保证映射规则长期一致。
SETBIT 写入用户 ID 时为什么必须转成偏移量，不能直接用 UID？
因为 SETBIT 操作的是一个位数组的**下标位置**（即 offset），不是用户 ID 本身。Redis Bitmap 本质是字符串，每个字节 8 位，offset 从 0 开始连续计数。如果你把用户 ID 123456789 直接当 offset 写进去，就等于在第 1.2 亿个 bit 上写值——这会撑爆内存、触发 Redis 的 string 长度限制（512MB），而且绝大多数位置都是稀疏空洞。
- 正确做法：用用户 ID 做哈希或取模，映射到合理范围，比如
uid % 10000000（覆盖千万级用户） - 更稳妥的方式是用
xxHash或MurmurHash对uid做一致性哈希，再对位图总长度取模，避免热点偏移 - 如果业务用户量稳定且已知上限（如 200 万），可直接用
uid作为 offset，但必须确保uid是连续正整数且从 0 或 1 开始
BITCOUNT 统计单日活跃时，KEY 名怎么设计才不串天？
Bitmap 是按 KEY 统计的，KEY 名必须带日期维度，否则所有天的数据混在一起，BITCOUNT 算出来的是累计值，不是日活。常见错误是固定用 user_active 这种 KEY，每天覆盖写，结果第二天一查，前一天数据没了；或者不清理旧 KEY，导致内存只增不减。
- 推荐格式：
active:20240520（年月日）或active:2024-05-20，用冒号分隔便于 scan 批量管理 - 写入前先确认当天 KEY 是否存在，不存在则无需
DEL；若需精确到小时，可用active:20240520:14 - 别用
SETBIT active:20240520 ${uid} 1后立刻BITCOUNT active:20240520—— 如果并发高，可能漏掉刚写入但未刷完的 bit，建议加小延迟或用 pipeline 包裹
为什么 BITCOUNT 在大 Bitmap 上变慢，以及怎么压低延迟？
BITCOUNT 时间复杂度是 O(N)，N 是字符串字节数。一个覆盖 1000 万用户的 Bitmap，底层字符串约 1.25MB（10^7 / 8），每次调用都要遍历全部字节。实测在普通 SSD + Redis 7.0 上，单次耗时可能达 3–8ms，QPS 上千时容易成为瓶颈。
- 用
BITCOUNT的start和end参数分片统计，比如每 64KB 一段，多线程/协程并行算再汇总（注意 Redis 单线程，实际是客户端并发） - 更常用的是预聚合：每天凌晨用
BITCOUNT算出当日值，存进另一个 KEY 如dau:20240520，查日活直接GET，毫秒级 - 避免在主从同步链路中高频调用
BITCOUNT，它不阻塞，但会增加主节点 CPU 和网络压力，尤其在从库上执行时可能拖慢同步
SETBIT + BITCOUNT 组合无法区分新老用户？那怎么补漏？
Bitmap 只记录“今天有没有活跃”，不保留历史状态。你没法从 active:20240520 和 active:20240519 两个 KEY 里直接算出“今天首次活跃的用户数”，因为 BITOP AND / XOR 能做集合运算，但需要手动维护多天 KEY，且 BITOP 生成的新 KEY 会额外占内存。
- 若只需“新增用户”指标，建议另起一套逻辑：用 HyperLogLog 存每日独立用户（
PFCOUNT快、省内存），再用PFDUMP+ 客户端比对（不推荐）或定期导出交集 - 更现实的做法是放弃纯 Redis 解决，用 Bitmap 存日活，同时往数仓写明细日志，新增用户数由离线任务计算后回填到 Redis 的
new_user:20240520 - 注意：不要对不同日期的 Bitmap 做
BITOP XOR后直接BITCOUNT当新增——如果某用户昨天活跃、今天也活跃，XOR 结果是 0；只有今天有、昨天无才是 1，这确实能算新增，但前提是两天 KEY 的 offset 映射规则完全一致，否则结果错得离谱
事情说清了就结束。最常被忽略的其实是 offset 映射的一致性——只要换了一次哈希函数或取模基数，历史 KEY 就废了，重算成本极高。
