最小可行路径是为每个用户创建独立Set键（如user:123:tags），用SADD添加标签、SMEMBERS查询，确保标签标准化；避免字符串拼接、KEYS扫描及反向索引维护，高频查询再引入RedisSearch或Elasticsearch。
用 SADD 和 SMEMBERS 管理用户标签的最小可行路径
Redis 的 Set 天然适合存用户标签——自动去重、无序、支持交并差。最直接的做法是：每个用户一个 key，比如 user:123:tags，每次打标就 SADD user:123:tags "vip" "ios" "active"，查标签就 SMEMBERS user:123:tags。
注意别把标签当字符串拼接存（如 SET user:123:tags "vip,ios,active"），那样后续增删改得取出来解析、再拼回去，既慢又容易出错。
-
SADD返回值是本次新增元素个数，可用来判断是否真打了新标签（返回 0 表示全已存在） - 标签名建议统一小写、去空格、避免特殊符号，否则
"VIP"和"vip"会被当成两个标签 - 如果用户量极大（千万级），
SMEMBERS全量拉取可能阻塞，后面会提到分页替代方案
批量查「有某几个标签」的用户要用 SSCAN + 应用层过滤，别硬扫
Redis 没有原生的“查所有带 vip 且带 ios 的用户”语法。想按标签反查用户，常见错误是建一堆反向索引 key（如 tag:vip:users），但维护成本高：用户删标签时得同步删多个地方，事务难保一致。
更务实的做法是：用 SSCAN 扫描所有 user:*:tags key，每次取一批（比如 SSCAN user:123:tags 0 COUNT 100），在应用代码里做集合判断（比如 Python 用 set(tags) >= {"vip", "ios"}）。
-
SSCAN是唯一安全遍历 Set 的方式，SMEMBERS在大数据量下会卡主线程 - 扫描前先用
KEYS user:*:tags？千万别——生产环境禁用，会阻塞 Redis；改用SCAN配合模式匹配 - 如果查询频次高、延迟敏感，再考虑用
RedisSearch或导出到 Elasticsearch 建倒排索引
SINTER 做多标签交集要小心 key 不存在或为空
想快速拿到“既是 vip 又是 ios 用户”的 ID 列表，可以为每个标签建一个用户 Set：tag:vip:users、tag:ios:users，然后 SINTER tag:vip:users tag:ios:users。
但这个操作很脆：只要其中一个 key 不存在，SINTER 就返回空结果，而不是忽略它；如果某个标签没人打，对应 key 根本没创建，结果也是空。
- 务必提前用
EXISTS检查每个 key 是否存在，不存在的先DEL或跳过参与交集 -
SINTER最多支持 2^16 个 key，但实际超过 5–10 个就明显变慢，建议拆成两两交集逐步缩小范围 - 交集结果如果很大（比如百万级用户），别直接
SMEMBERS，改用SSCAN流式处理
标签变更频繁时，用 SREM + SADD 组合比 DEL 更安全
用户编辑资料改标签，常见错误是先 DEL user:123:tags 再全量 SADD。这会导致中间状态丢失——万一 DEL 成功但 SADD 失败，用户就彻底没标签了。
正确做法是：先 SREM user:123:tags "old_tag1" "old_tag2" 删旧，再 SADD user:123:tags "new_tag1" "new_tag2" 加新。即使某步失败，至少数据不会清零。
-
SREM对不存在的元素静默忽略，不会报错；SADD对已存在元素也只返回 0，不影响逻辑 - 如果需要原子性（比如必须“删完再加完”才算成功），得用 Lua 脚本封装，但多数业务场景没必要
- 别用
SRANDMEMBER或SRANDMEMBER ... COUNT -n来模拟随机标签更新——那是读操作，不是更新手段
真正麻烦的不是存标签，而是标签语义漂移和生命周期管理。比如“trial”标签，过了七天该自动失效，但 Redis Set 本身不支持 TTL 单个元素——得靠外部定时任务清理，或者一开始就用带时间戳的复合结构（如 trial_20240520），这点很容易被忽略。
