sdiff 在 key 不存在时视为空集，易致过滤失效；建议用 exists 检查并预设空 key，避免客户端计算，大数据量时用 sdiffstore 缓存或分片+pipeline 优化，超万级黑名单可结合布隆过滤器预筛。
SDIFF 命令能直接算出两个 Set 的差集，但必须注意 key 不存在时的行为
Redis 的 SDIFF 返回第一个 key 中存在、而后续所有 key 中都不存在的元素。它不报错，但容易误判：如果某个参与运算的 key 不存在，Redis 会把它当作空集合处理。比如 SDIFF user:123:followed user:123:blocked，若 user:123:blocked 根本没建过，结果等价于全量返回 user:123:followed —— 黑名单过滤就完全失效了。
实操建议：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 上线前用
EXISTS检查黑名单 key 是否存在，不存在则显式SADD一个空值（或统一用SDIFF user:123:followed user:123:blocked dummy，其中dummy是预置的空 set） - 不要依赖客户端逻辑拼接“差集”，避免在应用层遍历比对 —— 网络往返 + 内存开销远高于服务端原生命令
- 若黑名单是动态生成的（如临时风控列表），优先用
SDIFFSTORE落到新 key，再SMEMBERS读取，避免多次调用SDIFF重复计算
黑名单数据量大时，SDIFF 性能会明显下降，别盲目套用
SDIFF 时间复杂度是 O(N+M)，其中 N 是第一个 key 的元素个数，M 是其余所有 key 元素总数。当你的关注列表有 50 万用户、黑名单有 2 万用户时，单次 SDIFF 可能卡住 200ms 以上，尤其在高并发场景下极易拖垮 Redis。
实操建议：
- 把高频访问的差集结果缓存为新 key（例如
user:123:followed:filtered），设置合理 TTL，用写时更新（write-through）策略维护一致性 - 黑名单超过 1 万条时，考虑拆成多个小集合（如按哈希尾号分片），用管道（pipeline）并行执行多个
SDIFF，再在客户端合并结果 —— 注意去重逻辑不能丢 - 若黑名单本身是关系型数据库导出的，可改用
SCAN+ 客户端布隆过滤器预筛，大幅减少传入SDIFF的候选集大小
SDIFF 不支持带条件的差集，比如“只过滤被封禁且创建时间
Redis Set 是无序无结构的纯字符串集合，SDIFF 只能做成员级存在性判断，无法结合其他字段（如封禁原因、时间戳）做复合过滤。一旦业务需要“封禁中且未申诉”的用户才过滤，SDIFF 就无能为力。
实操建议：
- 把多维状态压缩进 member 字符串，例如用
uid:status:ts格式存入黑名单，再配合SSCAN+ 正则匹配筛选，但会丧失原子性和性能 - 更稳妥的做法是放弃纯 Redis 方案：用黑名单 ID 列表查 MySQL 或 Elasticsearch，通过 JOIN 或 filter 获取满足条件的 ID，再用
SISMEMBER逐个验证关注列表中的用户 —— 虽然慢一点，但逻辑可控 - 如果必须强一致且低延迟，可将用户状态同步到 Redis Hash（
user_status:{uid}），用 Lua 脚本在服务端完成条件判断与差集逻辑，但脚本复杂度和调试成本会上升
用 SDIFF 实现黑名单过滤时，记得处理空结果和边界 case
常见错误现象包括：接口返回空数组却没报错、部分用户莫名消失、首次加载时数据不一致。这些往往不是 SDIFF 本身的问题，而是忽略了 Redis 的隐式语义。
实操建议：
- 始终检查
SDIFF返回数组长度，为 0 时不默认跳过，要确认是真无数据，还是因 key 不存在/类型错误导致“假空”（可用TYPE和EXISTS辅助诊断） - 关注列表和黑名单必须同属一个 Redis DB，跨 DB 无法直接运算；若用 Redis Cluster，确保两个 key 的 slot 相同（即 key 名加花括号保证 hash tag，如
{user:123}:followed和{user:123}:blocked） - 客户端收到
SDIFF结果后，别直接透传给前端 —— 至少做一次SISMEMBER随机抽检，防止中间发生 key 被误删或覆盖
SDIFF 都得扫描一遍，而开发者只盯着“当前有没有封禁”看。
