SISMEMBER 是检查用户当日签到的正确命令：返回1表示已签，0表示未签；它时间复杂度O(1)，但key不存在时也返回0，需配合EXISTS区分场景，且不支持模糊匹配或跨key查询。
用 SISMEMBER 检查用户是否在签到 Set 中
Redis 本身没有“签到”原语，但用 Set 存用户 ID 是最常见、最轻量的做法：SADD sign_in_20241025 user123 记录当天签到，再用 SISMEMBER sign_in_20241025 user123 查——返回 1 表示已签，0 表示未签。
注意：必须保证 key 名（如 sign_in_20241025）和用户 ID（如 user123）完全一致，大小写、前缀、编码都不能差一点。
为什么不用 EXISTS 或 GET？
EXISTS 只能判断 key 是否存在，无法判断某个用户是否在 Set 里；GET 对 Set 类型会直接报错 WRONGTYPE Operation against a key holding the wrong kind of value。只有集合类命令才能操作 Set。
常见误操作：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 对
Setkey 执行GET—— 报错 - 用
HMGET查哈希表式签到结构 —— 完全不匹配场景 - 把用户 ID 当成整数传入（比如传
123而不是"123"），而 Redis 不自动类型转换，字符串"123"和数字123是两个不同元素
SISMEMBER 的性能和边界情况
SISMEMBER 时间复杂度是 O(1)，无论 Set 里有 10 个还是 10 万个用户，响应都很快。但它不支持通配符或模糊匹配，也不能跨 key 查询。
容易被忽略的点：
- key 不存在时，
SISMEMBER返回0（不是空或 nil），和“key 存在但用户不在”表现一致，所以不能靠返回值反推 key 是否存在 - 如果业务需要区分“从未建过今日签到 key”和“建了但该用户没签”，得额外用
EXISTS先查 key - 用户 ID 含空格、冒号、斜杠等特殊字符时，确保客户端没做意外截断或 URL 解码（比如
user:id:789在 HTTP 参数里可能被误处理）
别把签到逻辑全压给 Redis
Redis 只负责“存”和“查”，不负责“限频”“校验时间”“生成签到奖励”。比如用户重复请求签到，应用层得先用 SISMEMBER 判断，再决定是否执行 SADD，而不是无脑 SADD 后再查——虽然 SADD 本身幂等，但多一次网络往返不划算。
更关键的是：不要在 Lua 脚本里把“查+加”写成两步（先 SISMEMBER 再 SADD），这会有竞态。真要原子性，直接用 SADD + 客户端判断返回值是否为 1（表示本次是新增）。
