SISMEMBER 是唯一推荐的 O(1) 判断方式，返回 0 需结合 EXISTS 区分 key 不存在或 member 不存在；Python 中应显式判断 == 1 并捕获异常；避免 Lua 中拆分 SISMEMBER+SADD，改用 SADD 返回值实现幂等；注意 member 字符串编码与 key 生命周期管理。
SISMEMBER 是唯一推荐的、O(1) 时间复杂度的判断方式，别用 SMEMBERS + Python in 遍历，也别手写 Lua 脚本查完再加——既慢又容易出竞态。
为什么 SISMEMBER 返回 0 不代表“元素一定不存在”
它返回 0 有两种可能：key 根本没建过，或者 key 存在但 member 确实不在集合里。这两者业务语义常不同——比如签到场景，“今天没人签过”和“用户 A 没签”要走不同分支。
若需区分，必须先执行 EXISTS key：
SISMEMBER today_sign:20260525 user:123<br>EXISTS today_sign:20260525
两个命令一起跑，客户端根据组合结果判断。别省这一步，否则后续逻辑容易误判。
Python 中用 redis-py 调用 sismember 的坑
返回值是整数 1 或 0，不是布尔值。直接写 if r.sismember("myset", "x"): 虽然能运行，但语义模糊，且容易和异常混淆（比如网络断连时抛 ConnectionError，不是返回 0）。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 显式比对：
if r.sismember("myset", "x") == 1: - 封装成布尔函数时，加 try/except 包裹网络异常，不要让
0和异常混为一谈 - 注意
member是字符串类型；传入int或bytes可能导致匹配失败（如 Python 里r.sismember("s", 123)≠r.sismember("s", "123")）
别在 Lua 脚本里拆成 SISMEMBER + SADD 两步
看似原子，实则中间有窗口：脚本执行完 SISMEMBER 后、还没走到 SADD 前，另一个客户端可能已插入同一元素，造成重复逻辑或状态不一致。
正确做法：
- 如果只是“判断后决定是否加”，用
SADD返回值：它返回1表示本次新增，0表示已存在——天然幂等，且单命令原子 - 如果真需要“查+条件性操作”（比如查到存在才发奖励），改用
EVAL脚本，但必须把整个判断和副作用写进一个return表达式，不能分步调用 Redis 命令 - 避免把
SISMEMBER当作“读取开关”去控制外部业务流程分支——Redis 不该承担这个协调职责
特殊字符和编码问题实际影响很大
用户 ID 或业务标识含冒号、空格、斜杠时，member 字符串在 HTTP 请求、日志解析、配置文件中极易被截断或二次解码。例如 user:id:789 在 URL query string 里可能变成 user%3Aid%3A789，若客户端没自动 decode 就直接传给 sismember，就会查不到。
建议统一处理策略：
- 所有写入前做
urllib.parse.quote（或等效编码），读取时对应unquote - 或约定只用 Base64 编码原始 ID，避开所有保留字符
- 调试时用
SMEMBERS key直接看集合内容，确认存进去的字符串长什么样，而不是只信日志或变量名
最常被跳过的其实是 key 生命周期管理——SISMEMBER 查不到，第一反应不该是“是不是拼错了 member”，而是“这个 key 到底有没有被创建过？有没有被 EXPIRE 掉？有没有被其他服务误删？”。查之前先 EXISTS，比反复重试更省资源。
