11-Redis 集合类型深度指南：从去重特性到集合运算场景落地

11-Redis 集合类型深度指南：从去重特性到集合运算场景落地 - 详解

2025-10-12 20:28 tlnshuju 阅读(0) 评论(0) 收藏举报

前言
一、为什么集合类型是 Redis 的 “去重与关联分析利器”？
二、Redis 集合类型的核心特性：基于哈希表的 “唯一与高效”
- 2.1 底层实现：哈希表的 “优势加持”
- 2.2 存储特性：三大核心规则
- 2.3 与其他类型的差异：明确适用边界
三、集合类型核心命令实操：8 大类命令全掌握
- 3.1 元素增删：SADD 与 SREM（核心高频命令）
- - （1）命令格式与功能
  - （2）实操案例
  - （3）关键注意
- 3.2 全量查询元素：SMEMBERS
- - （1）命令格式与返回值
  - （2）实操案例
  - （3）性能风险提示
- 3.3 元素存在性判断：SISMEMBER（高效校验）
- - （1）命令格式与返回值
  - （2）实操案例
  - （3）使用场景
- 3.4 集合间运算：SDIFF、SINTER、SUNION（关联分析核心）
- - （1）命令格式与功能
  - （2）实操案例
  - （3）业务价值
- 3.5 元素个数统计：SCARD（高效计数）
- - （1）命令格式与返回值
  - （2）实操案例
  - （3）使用场景
- 3.6 集合运算并存储结果：SDIFFSTORE、SINTERSTORE、SUNIONSTORE
- - （1）命令格式与功能
  - （2）实操案例
  - （3）适用场景
- 3.7 随机获取元素：SRANDMEMBER（随机抽样）
- - （1）命令格式与规则
  - （2）实操案例
- 3.8 随机弹出元素：SPOP（随机删除）
- - （1）命令格式与返回值
  - （2）实操案例
  - （3）与`SRANDMEMBER`的差异
四、集合类型典型业务场景：适配 “去重 + 集合运算” 需求
- 4.1 存储文章标签（去重场景）
- - （1）实现方案
  - （2）实操示例
  - （3）优势对比
- 4.2 标签交集文章查询（集合运算场景）
- - （1）实现方案
  - （2）实操示例
- 4.3 存储用户好友列表（去重 + 共同好友场景）
- - （1）实现方案
  - （2）实操示例
五、集合类型避坑指南：新手常犯的 4 个错误
- 5.1 坑 1：依赖`SMEMBERS`的返回顺序，导致业务逻辑错误
- 5.2 坑 2：误解`SADD`的返回值，误判命令执行结果
- 5.3 坑 3：大集合使用`SMEMBERS`，导致服务阻塞
- 5.4 坑 4：差集运算忽略键顺序，导致结果错误
六、总结：集合类型的学习与进阶建议

前言

在 Redis 的 6 种核心数据类型中，集合类型（set）是专为 “无重复数据存储” 与 “多集合关联分析” 设计的利器。它基于哈希表实现，既能高效完成元素去重（如文章标签、用户好友列表），又能快速执行差集、交集、并集等运算（如查询共同好友、标签交集文章），完美解决传统关系数据库在 “去重” 与 “关联分析” 场景中的性能痛点。本文从核心特性、命令实操、场景落地到避坑指南，全方位拆解 Redis 集合类型，帮你掌握其在 “去重 + 集合运算” 场景中的高效用法。

一、为什么集合类型是 Redis 的 “去重与关联分析利器”？

集合类型（set）的核心特点是 “元素唯一” 与 “无顺序”，其底层基于值为空的哈希表（hash table）实现 —— 这种结构赋予了它两大关键优势：一是增删元素、判断元素是否存在的时间复杂度均为 O(1)，无论集合包含 10 个还是 100 万个元素，操作速度几乎无差异；二是天然支持元素去重，重复添加的元素会被自动忽略，无需额外编码处理。

集合类型的核心价值体现在三个方面：

解决数据去重痛点：传统关系数据库需通过DISTINCT关键字或唯一索引实现去重，性能低下且操作复杂；而 Redis 集合的SADD命令会自动过滤重复元素，仅需一行命令即可完成去重存储。
简化多集合关联分析：查询 “同时包含多个标签的文章”“两个用户的共同好友” 等场景，在关系数据库中需多表关联，SQL 语句复杂且效率低；Redis 集合的SINTER（交集）命令可直接实现，代码简洁且性能优异。
轻量高效：集合元素仅支持字符串类型，存储结构简单，内存占用低，远超其他需额外维护索引的去重方案（如数据库唯一索引）。

对于新手而言，理解集合类型的 “哈希表底层” 与 “无顺序特性” 是关键 —— 它决定了集合的 “优势场景”（去重、集合运算）与 “劣势场景”（需固定顺序的数据存储），直接影响后续命令选择与业务适配。

二、Redis 集合类型的核心特性：基于哈希表的 “唯一与高效”

要用好集合类型，首先需深入理解其底层特性与存储规则，避免因误解结构导致使用场景偏差。集合类型的核心特性可拆解为三点：

2.1 底层实现：哈希表的 “优势加持”

Redis 集合的底层是哈希表，这种结构就像现实中 “无重复标签的收纳盒”—— 每个标签（集合元素）仅能出现一次，且无需按固定顺序摆放：

元素唯一性：哈希表的 “键不可重复” 特性决定了集合元素的唯一性。当执行SADD命令添加已存在的元素时，Redis 会通过哈希函数定位到该元素的位置，发现已存在后自动忽略，仅返回 “新增成功的元素个数”（重复元素不计数）。
O(1) 操作效率：无论是添加元素（SADD）、删除元素（SREM），还是判断元素是否存在（SISMEMBER），都能通过哈希函数直接定位元素位置，无需遍历整个集合，时间复杂度均为 O(1)。这意味着即使集合包含 100 万个元素，判断某个元素是否存在也能瞬间完成。
无顺序性：哈希表存储数据时无固定顺序，集合元素的返回顺序（如SMEMBERS命令）也随机，与插入顺序无关。例如执行SADD set a b c后，SMEMBERS set可能返回["b","a","c"]，这是哈希表的天然特性，需在业务中接受这种无序性。

2.2 存储特性：三大核心规则

元素仅支持字符串：与列表、哈希类型一致，集合元素只能是字符串，不支持嵌套其他数据类型（如集合中不能包含哈希、列表）。若需存储复杂数据（如用户信息），需先将其序列化为字符串（如 JSON 格式）再存入。
无固定容量上限：单个集合最多可容纳 $2^{32}-1$ 个元素，远超多数业务场景的需求，无需担心容量不足问题。
空集合自动清理：当集合中的元素被全部删除（如SREM删除所有元素）后，Redis 会自动清理该集合占用的内存，无需手动删除空集合键。

2.3 与其他类型的差异：明确适用边界

为避免场景错位，需清晰区分集合类型与列表、有序集合类型的差异，通过对比突出了集合的独特性：

对比维度	集合类型（set）	列表类型（list）	有序集合类型（zset）
元素唯一性	唯一（不允许重复）	允许重复	元素唯一，分数可重复
有序性	无顺序（哈希表存储，返回随机）	插入顺序有序，支持正向 / 反向遍历	按分数自动排序，元素顺序固定
核心操作效率	增删查 O(1)，支持差集 / 交集 / 并集	两端增删 O(1)，中间访问 O(n)	增删查 O(logn)，支持分数排序
适用场景	去重集合（标签、好友）、关联分析	时序数据（日志、新鲜事）	带权重排序（排行榜、计分板）

简单来说：需要 “去重” 或 “多集合关联分析” 选集合；需要 “按时间顺序存储” 选列表；需要 “按分数 / 权重排序” 选有序集合 —— 三者各自适配不同场景，无绝对优劣，关键在于业务需求匹配。

三、集合类型核心命令实操：8 大类命令全掌握

集合类型的 8 大类核心命令，涵盖元素增删、查询、集合运算等全场景需求。下面结合文档示例，逐一拆解命令用法与注意事项，帮你快速上手实操。

3.1 元素增删：SADD 与 SREM（核心高频命令）

SADD和SREM是集合类型最基础的 “写入 - 删除” 工具，直接利用哈希表的 O(1) 操作特性，是日常开发中使用频率最高的命令。

（1）命令格式与功能

命令	功能描述
`SADD key member...`	向集合添加 1 个或多个元素，返回新增成功的元素个数（已存在元素不计数），集合不存在时自动创建
`SREM key member...`	从集合删除 1 个或多个元素，返回删除成功的元素个数（不存在元素不计数），集合为空后自动清理

（2）实操案例

# 1. 向集合添加元素（含重复元素）
127.0.0.1:6379> SADD letters a  # 首次添加a，新增1个元素
(integer) 1
127.0.0.1:6379> SADD letters a b c  # a已存在，仅新增b、c，共2个
(integer) 2
# 此时集合letters：{a, b, c}
# 2. 从集合删除元素（含不存在元素）
127.0.0.1:6379> SREM letters c d  # c存在（删除），d不存在（忽略），共删除1个
(integer) 1
# 此时集合letters：{a, b}

（3）关键注意

SADD无需先判断元素是否存在：命令会自动忽略重复元素，无需额外执行SISMEMBER判断，减少代码复杂度；
SREM删除不存在元素无报错：即使传入不存在的元素，命令也仅返回 0（删除个数），不会抛出错误，无需担心异常处理。

3.2 全量查询元素：SMEMBERS

当需要获取集合中所有元素时，SMEMBERS是核心命令，但需注意其 “返回顺序随机” 的特性。

（1）命令格式与返回值

格式：SMEMBERS key
返回值：集合中所有元素的列表，元素顺序随机（与插入顺序无关）；集合不存在时返回空列表。

（2）实操案例

# 集合letters当前元素：{a, b}
127.0.0.1:6379> SMEMBERS letters
1) "b"  # 顺序随机，可能与插入顺序（a先、b后）不同
2) "a"
# 查询不存在的集合
127.0.0.1:6379> SMEMBERS empty:set
(empty array)  # 返回空列表

（3）性能风险提示

当集合包含大量元素（如超过 10 万个）时，SMEMBERS会一次性返回所有元素，可能占用大量网络带宽并阻塞 Redis 单线程，影响其他业务。生产环境中若需遍历大集合，建议改用SSCAN命令（非阻塞遍历，分批次返回元素），该命令虽属于进阶内容，但需了解其存在以应对大集合场景。

3.3 元素存在性判断：SISMEMBER（高效校验）

SISMEMBER是集合类型的 “性能亮点” 命令，通过哈希表直接定位元素，时间复杂度 O(1)，远超列表的 “遍历判断” 方式。

（1）命令格式与返回值

格式：SISMEMBER key member
返回值：元素存在返回1，元素不存在或集合不存在返回0。

（2）实操案例

# 集合letters当前元素：{a, b}
127.0.0.1:6379> SISMEMBER letters a  # a存在，返回1
(integer) 1
127.0.0.1:6379> SISMEMBER letters d  # d不存在，返回0
(integer) 0
# 查询不存在的集合的元素
127.0.0.1:6379> SISMEMBER no:set a  # 集合不存在，返回0
(integer) 0

（3）使用场景

校验标签是否已添加（如判断文章是否已包含 “Redis” 标签）；
验证用户是否为好友（如判断用户 101 是否在用户 100 的好友列表中）；
替代列表的 “遍历判断”：列表需通过LRANGE获取所有元素后在客户端遍历，而SISMEMBER直接返回结果，效率提升显著。

3.4 集合间运算：SDIFF、SINTER、SUNION（关联分析核心）

集合运算（差集、交集、并集）是集合类型的 “核心竞争力”，能快速解决多集合关联分析问题，这是列表、有序集合类型无法替代的优势。
在这里插入图片描述

（1）命令格式与功能

命令	功能描述	结果规则
`SDIFF key1 key2...`	计算差集（属于 key1 但不属于其他集合的元素）	键顺序影响结果（`SDIFF A B` = A - B，而非 B - A）
`SINTER key1 key2...`	计算交集（同时属于所有集合的元素）	键顺序不影响结果（`SINTER A B` = `SINTER B A`）
`SUNION key1 key2...`	计算并集（属于任一集合的元素，自动去重）	键顺序不影响结果（`SUNION A B` = `SUNION B A`）

（2）实操案例

# 先创建3个测试集合
127.0.0.1:6379> SADD setA 1 2 3  # setA：{1,2,3}
(integer) 3
127.0.0.1:6379> SADD setB 2 3 4  # setB：{2,3,4}
(integer) 3
127.0.0.1:6379> SADD setC 2 3    # setC：{2,3}
(integer) 2
# 1. 差集：setA - setB - setC（属于setA，不属于setB和setC）
127.0.0.1:6379> SDIFF setA setB setC
1) "1"  # 仅1符合条件
# 2. 交集：setA ∩ setB ∩ setC（同时属于3个集合）
127.0.0.1:6379> SINTER setA setB setC
1) "2"
2) "3"  # 2、3同时在3个集合中
# 3. 并集：setA ∪ setB ∪ setC（属于任一集合，自动去重）
127.0.0.1:6379> SUNION setA setB setC
1) "1"
2) "2"
3) "3"
4) "4"  # 4个元素，无重复

（3）业务价值

差集：查询 “用户 A 关注但用户 B 未关注的账号”（SDIFF user:A:follow user:B:follow）；
交集：查询 “同时包含‘Java’和‘Redis’标签的文章”（SINTER tag:Java:posts tag:Redis:posts）；
并集：统计 “用户 A 和用户 B 的所有共同好友总数”（SCARD SUNION user:A:friends user:B:friends）。

3.5 元素个数统计：SCARD（高效计数）

SCARD命令用于统计集合中的元素总数，时间复杂度 O(1)——Redis 内部维护了元素计数器，无需遍历集合，性能远超关系数据库的COUNT(*)。

（1）命令格式与返回值

格式：SCARD key
返回值：集合元素个数，集合不存在时返回0。

（2）实操案例

# 集合setA当前元素：{1,2,3}
127.0.0.1:6379> SCARD setA
(integer) 3
# 统计不存在的集合
127.0.0.1:6379> SCARD no:set
(integer) 0

（3）使用场景

统计文章标签总数（SCARD post:42:tags）；
计算共同好友个数（SCARD SINTER user:100:friends user:101:friends）；
监控集合大小是否超出阈值（如限制用户好友数不超过 500，用SCARD判断）。

3.6 集合运算并存储结果：SDIFFSTORE、SINTERSTORE、SUNIONSTORE

当需要将集合运算的结果长期保存（而非仅临时查看）时，这组命令能将运算结果存储到指定键中，支持多步集合运算（如先算差集再算交集）。

（1）命令格式与功能

与SDIFF/SINTER/SUNION功能一致，唯一区别是将结果存储到destination键中，返回值为结果集合的元素个数：

SDIFFSTORE destination key1 key2...
SINTERSTORE destination key1 key2...
SUNIONSTORE destination key1 key2...

（2）实操案例

# 计算setA与setB的交集，存储到setA_B_inter中
127.0.0.1:6379> SINTERSTORE setA_B_inter setA setB
(integer) 2  # 交集含2个元素（2、3）
# 查看存储的交集结果
127.0.0.1:6379> SMEMBERS setA_B_inter
1) "2"
2) "3"

（3）适用场景

多步运算：先计算 “用户 A 的好友 - 用户 A 的黑名单”（SDIFFSTORE temp user:A:friends user:A:blacklist），再计算该结果与 “用户 B 的好友” 的交集（SINTERSTORE common_friends temp user:B:friends）；
结果缓存：将高频使用的集合运算结果（如 “热门标签交集文章”）存储，避免重复运算，提升性能。

3.7 随机获取元素：SRANDMEMBER（随机抽样）

SRANDMEMBER命令能从集合中随机获取元素，支持指定获取数量，且可控制是否允许重复，适合随机推荐、抽样统计等场景。

（1）命令格式与规则

格式：SRANDMEMBER key [count]
count参数规则：
- count > 0：获取count个不重复元素（数量超过集合元素数时，返回所有元素）；
- count < 0：获取count个元素，允许重复（数量可超过集合元素数）；
- 不填count：默认获取 1 个不重复元素。

（2）实操案例

# 先向letters集合添加元素，当前集合：{a, b, c, d}
127.0.0.1:6379> SADD letters c d
# 1. count>0：获取2个不重复元素
127.0.0.1:6379> SRANDMEMBER letters 2
1) "b"
2) "c"  # 无重复
# 2. count<0：获取3个元素，允许重复
127.0.0.1:6379> SRANDMEMBER letters -3
1) "a"
2) "c"
3) "a"  # 重复元素
# 3. 不填count：获取1个元素
127.0.0.1:6379> SRANDMEMBER letters
"d"

3.8 随机弹出元素：SPOP（随机删除）

SPOP命令从集合中随机弹出 1 个元素（删除并返回），与LPOP/RPOP（列表两端弹出）的固定方向不同，SPOP的弹出位置完全随机，适合 “随机抽奖”“随机移除元素” 场景。

（2）实操案例

# 集合letters当前元素：{a, b, c, d}
127.0.0.1:6379> SPOP letters
"a"  # 随机弹出a，集合变为{b, c, d}
# 再次弹出
127.0.0.1:6379> SPOP letters
"c"  # 集合变为{b, d}

（3）与`SRANDMEMBER`的差异

SPOP：弹出元素（删除 + 返回），会修改原集合；
SRANDMEMBER：仅获取元素，不修改原集合 —— 需根据 “是否删除元素” 选择命令，如抽奖场景需删除已中奖用户，用SPOP；仅随机展示不删除，用SRANDMEMBER。

四、集合类型典型业务场景：适配 “去重 + 集合运算” 需求

集合类型的典型应用场景主要有三类，均围绕 “去重” 或 “集合运算” 展开，覆盖多数日常开发需求。

4.1 存储文章标签（去重场景）

博客、资讯类平台的文章标签需满足 “唯一不重复”，且支持单独添加 / 删除标签 —— 集合类型的SADD（自动去重）、SREM（单独删除）特性能完美适配。

（1）实现方案

键名设计：post:文章ID:tags（如post:42:tags存储文章 42 的所有标签）；
添加标签：用SADD post:42:tags 标签1 标签2...，自动忽略重复标签；
删除标签：用SREM post:42:tags 标签1，单独删除指定标签；
展示标签：用SMEMBERS post:42:tags，获取所有标签后在前端展示。

（2）实操示例

# 给文章42添加“Java”“Redis”“技术文章”3个标签
127.0.0.1:6379> SADD post:42:tags Java Redis 技术文章
(integer) 3  # 新增3个标签，集合：{Java, Redis, 技术文章}
# 误添加重复标签“Java”，自动忽略
127.0.0.1:6379> SADD post:42:tags Java
(integer) 0  # 无新增元素
# 删除“技术文章”标签
127.0.0.1:6379> SREM post:42:tags 技术文章
(integer) 1  # 集合变为{Java, Redis}
# 展示文章42的所有标签
127.0.0.1:6379> SMEMBERS post:42:tags
1) "Java"
2) "Redis"

（3）优势对比

相比用字符串类型存储标签（如 “Java;Redis; 技术文章”），集合类型的优势在于：

无需手动处理去重（SADD自动过滤）；
支持单独删除标签（SREM直接删除，无需拆分字符串）；
可快速判断标签是否存在（SISMEMBER，避免重复添加）。

4.2 标签交集文章查询（集合运算场景）

用户查询 “同时包含‘Java’和‘Redis’标签的文章” 是典型的多集合关联分析需求，传统关系数据库需多表关联（文章表、标签表、文章 - 标签关联表），SQL 复杂且效率低；而 Redis 集合的SINTER命令可直接实现，代码简洁且性能优异。

（1）实现方案

键名设计：为每个标签创建集合tag:标签名:posts（如tag:Java:posts存储含 “Java” 标签的所有文章 ID，tag:Redis:posts存储含 “Redis” 标签的所有文章 ID）；
标签关联文章：当文章 42 添加 “Java” 标签时，执行SADD tag:Java:posts 42；
交集查询：用SINTER tag:Java:posts tag:Redis:posts，获取同时含两个标签的文章 ID；
文章展示：根据返回的文章 ID，从数据库或缓存中获取文章详情并展示。

（2）实操示例

# 给“Java”标签添加文章1、2、3
127.0.0.1:6379> SADD tag:Java:posts 1 2 3
(integer) 3
# 给“Redis”标签添加文章2、3、4
127.0.0.1:6379> SADD tag:Redis:posts 2 3 4
(integer) 3
# 查询同时含“Java”和“Redis”标签的文章ID
127.0.0.1:6379> SINTER tag:Java:posts tag:Redis:posts
1) "2"
2) "3"  # 文章2、3同时含两个标签
# 统计交集文章数量
127.0.0.1:6379> SCARD SINTER tag:Java:posts tag:Redis:posts
(integer) 2

4.3 存储用户好友列表（去重 + 共同好友场景）

社交平台的用户好友列表需满足 “好友 ID 唯一”，且需支持 “查询共同好友”—— 集合类型的去重特性与SINTER命令能高效实现这两个需求。

（1）实现方案

键名设计：user:用户ID:friends（如user:100:friends存储用户 100 的好友 ID，user:101:friends存储用户 101 的好友 ID）；
添加好友：用SADD user:100:friends 102 103，自动避免重复添加；
删除好友：用SREM user:100:friends 102，单独删除指定好友；
查询共同好友：用SINTER user:100:friends user:101:friends，获取两人的共同好友 ID。

（2）实操示例

# 存储用户100的好友：102、103、104
127.0.0.1:6379> SADD user:100:friends 102 103 104
(integer) 3
# 存储用户101的好友：103、104、105
127.0.0.1:6379> SADD user:101:friends 103 104 105
(integer) 3
# 查询用户100与101的共同好友
127.0.0.1:6379> SINTER user:100:friends user:101:friends
1) "103"
2) "104"  # 共同好友为103、104
# 统计共同好友数量
127.0.0.1:6379> SCARD SINTER user:100:friends user:101:friends
(integer) 2

五、集合类型避坑指南：新手常犯的 4 个错误

即使掌握了命令格式，新手仍可能因忽视细节或误解特性导致问题。以下是 4 个高频坑点及解决方案，帮你少走弯路。

5.1 坑 1：依赖`SMEMBERS`的返回顺序，导致业务逻辑错误

现象：执行SADD set a b c后，预期SMEMBERS set返回[a,b,c]，但实际返回[b,a,c]，导致前端标签展示顺序混乱，与设计图不符。

原因：集合基于哈希表存储，无固定顺序，SMEMBERS的返回顺序由哈希函数决定，与插入顺序无关 —— 这是集合类型的天然特性，而非命令 bug。

解决方案：

需固定顺序时改用有序集合（zset）：通过为元素设置连续分数（如 a→1、b→2、c→3），用ZRANGE按分数排序返回，保证顺序固定；
无需严格顺序时接受随机性：标签、好友列表等场景通常无需固定顺序，前端可通过样式（如按字母排序）统一展示，避免依赖SMEMBERS的返回顺序。

5.2 坑 2：误解`SADD`的返回值，误判命令执行结果

现象：执行SADD set a a b后，返回值为2，而非预期的3，误以为命令未添加所有元素，反复执行导致无效操作。

原因：SADD的返回值是 “新增成功的元素个数”，而非 “总添加元素个数”—— 重复元素a仅新增 1 次，b新增 1 次，共 2 个新增元素，返回2是正确结果。

解决方案：

明确SADD返回值含义：无需判断元素是否存在，直接执行SADD即可，返回值仅用于统计新增数量，不代表命令执行失败；
避免重复执行：即使返回0（无新增元素），也说明元素已存在，无需再次执行，减少 Redis 请求次数。

5.3 坑 3：大集合使用`SMEMBERS`，导致服务阻塞

现象：对包含 100 万个元素的集合执行SMEMBERS，命令执行耗时超过 2 秒，期间 Redis 无法处理其他请求，业务出现超时。

原因：SMEMBERS会一次性返回所有元素，大集合的数据量过大（如每个元素 10 字节，100 万个元素即 10MB），会占用大量网络带宽，并阻塞 Redis 单线程（Redis 为单线程模型，长时间命令会阻塞后续请求）。

解决方案：

大集合改用SSCAN遍历：SSCAN采用非阻塞方式，分批次返回元素（如每次返回 100 个），不会阻塞服务，格式为SSCAN key cursor MATCH * COUNT 100；
避免全量查询：业务中尽量避免 “获取所有元素” 的需求，如统计标签总数用SCARD，判断元素存在用SISMEMBER，减少全量查询场景。

5.4 坑 4：差集运算忽略键顺序，导致结果错误

现象：想计算 “用户 A 的好友 - 用户 A 的黑名单”（即用户 A 的有效好友），执行SDIFF user:A:blacklist user:A:friends，得到 “黑名单 - 好友” 的结果，与预期完全相反。

原因：SDIFF的键顺序直接影响结果 ——SDIFF key1 key2的逻辑是 “属于 key1 且不属于 key2”，而非 “属于 key2 且不属于 key1”，交集（SINTER）、并集（SUNION）不受键顺序影响，但差集受影响。

解决方案：

执行差集前明确 “主集合” 与 “排除集合”：按 “主集合在前，排除集合在后” 的顺序传入键，如 “好友 - 黑名单” 应执行SDIFF user:A:friends user:A:blacklist；
执行后验证结果：重要场景执行差集后，用SMEMBERS查看结果，确认与预期一致，避免因顺序错误导致业务问题。