用SETBIT而非SET存在线状态，因位图内存仅约12.5MB（1亿用户），支持秒级统计与集合运算；需确保用户ID为非负整数、key带日期并设过期，用BITFIELD批量操作，BITCOUNT统计时注意写入逻辑与精度。
为什么用 SETBIT 而不是 SET 存在线状态
直接存字符串（比如 SET user:1001 online）看似简单，但 1 亿用户就占 1 亿个 key，内存爆炸，且无法快速统计“今天上线了多少人”。SETBIT 把用户 ID 当作位偏移量，用单个 String 的二进制位表示在线/离线，1 亿用户 ≈ 12.5 MB 内存，还能秒级做交集、并集、计数。
常见错误现象：SETBIT user:online:20240520 1001 1 后查不到——因为没确认 key 是否过期、是否被误删；或用户 ID 是字符串如 "u_1001"，而 SETBIT 只接受非负整数偏移量，会报错 ERR bit offset is not an integer or out of range。
- 用户 ID 必须转成纯数字，且从 0 开始连续更省空间（不连续也没问题，只是中间空位也占内存）
- key 名建议带日期，如
user:online:20240520，避免无限累积；用EXPIRE设置 24–48 小时过期 - 不要用
HSET或SET模拟位图——没有原生命令快，也不支持BITCOUNT这类聚合
GETBIT 返回值是 0/1，但容易误解为“存在与否”
GETBIT 查的是某一位的值，不是 key 是否存在。如果 key 不存在，它默认返回 0，而不是 nil 或 error。这意味着你不能靠 GETBIT 返回 0 就断定“用户不在线”，也可能是 key 根本没建过。
使用场景：心跳检测、实时在线判断。例如定时任务检查用户 1001 今天是否上线：GETBIT user:online:20240520 1001。
- 务必先确保 key 已创建（哪怕只执行一次
SETBIT user:online:20240520 0 0初始化） - 若需区分“未设置”和“明确设为离线”，得配合
EXISTS判断 key 是否存在：EXISTS user:online:20240520 - 注意：Redis 位图是稀疏存储，高位未写过的区域不实际分配内存，所以
GETBIT查一个超大 offset（如 10亿）不会 OOM，但会略慢
批量操作用 BITFIELD，别拼多个 SETBIT
给 1000 个用户同时标记在线，用循环发 1000 次 SETBIT 请求？网络开销大、原子性差、还可能部分失败。这时候该上 BITFIELD——它支持单命令多操作，且全部原子执行。
示例：把用户 1001、1005、1024 设为在线（值为 1），并读取 1001 当前状态：
BITFIELD user:online:20240520 SET i1 1001 1 SET i1 1005 1 SET i1 1024 1 GET i1 1001
参数差异：i1 表示有符号 1 位整数（实际只用 0/1），也可用 u1（无符号）。别写成 i8——浪费空间，且后续 BITCOUNT 仍按位算，不影响结果但易误导。
-
BITFIELD命令在 Redis 6.2+ 默认开启；老版本需确认配置中bitmap-max-bytes未被设为 0 - 如果操作跨天（比如凌晨写昨天的 key），注意 key 名要动态计算，别硬编码
- 不支持在
BITFIELD里直接设过期时间，EXPIRE得单独调用
统计日活用 BITCOUNT，但要注意 key 生命周期和精度
BITCOUNT user:online:20240520 是最常用也最容易翻车的操作。表面看是统计“有多少位是 1”，但实际含义取决于你怎么写入：是每次登录设 1，还是每次心跳都设 1？后者会导致重复计数。
性能影响：对一个 1 亿用户的位图，BITCOUNT 在现代 Redis（6.0+）里是 O(1)，因为内部用了 popcount 优化；但若 key 特别大（比如几百 MB），首次执行仍可能短暂阻塞主线程。
- 推荐每天零点用
BITCOUNT+DEL组合导出数据，再删旧 key，避免长期堆积 - 如果需要“最近 7 天活跃用户数”，别用 7 个
BITCOUNT相加——要用BITOP AND先算交集，再BITCOUNT，否则重复用户会被重复计算 - 注意：
BITCOUNT统计的是整个 key 的所有位，如果你只写了前 10 万个用户，后面 9000 万位全是 0，它照样扫完——所以 key 范围要尽量贴近真实用户 ID 上限
真正难的不是命令怎么敲，而是设计时想清楚：用户 ID 是否全局连续、过期策略怎么配、跨天数据怎么衔接、以及——当运营突然要查“过去 30 天每天的独立访客”，你有没有预留好每天一个 key 的结构。
