SINTER是唯一靠谱的共同好友计算方式，因其在Redis服务端毫秒级完成原子集合交集运算，避免客户端遍历的网络开销、内存膨胀与循环性能损耗。

为什么SINTER是唯一靠谱的共同好友计算方式

别用SMEMBERS拉取双方好友列表再在应用层循环比对——这等于把Redis当网盘使，丢掉了它最核心的原子集合运算能力。真正高效的做法是让交集计算完全发生在Redis服务端：SINTER直接在内存里完成集合求交，毫秒级返回结果，且自动选取最小集合做主干扫描，时间复杂度接近 O(N×M)（N为最小集合大小，M为参与集合数）。而客户端遍历至少多出3次网络往返、内存膨胀风险、以及重复嵌套循环开销。

调用SINTER前必须确认的三件事

实际出错往往不是命令写错，而是数据结构没对齐：

• 所有key必须是Set类型，混入String或Hash会直接报WRONGTYPE错误
• 每个集合成员必须是标准用户ID（如"u1001"），不能带时间戳、状态标记等额外字段，否则SINTER会把整个字符串当元素比对，导致逻辑错误
• key命名需兼容集群路由：若用Redis Cluster，所有参与SINTER的key必须落在同一slot，否则报CROSSSLOT Keys in request don't hash to the same slot；解决方法是加哈希标签，例如改用friends:{u1001}和friends:{u1002}

SINTER返回空结果不等于出错，但业务逻辑常在这里翻车

SINTER对任意一个key不存在的情况，返回空集合（[]），而不是抛异常。很多开发者误以为这是错误信号，其实这是正常行为——你需要判断SCARD结果是否为0，而不是依赖try-catch捕获异常。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

更隐蔽的问题是大集合响应压垮client buffer：如果共同好友可能上万，避免直接SINTER key1 key2返回全量ID。应改用SINTERSTORE temp:cf:u1001_u1002 key1 key2先存结果，再用SRANDMEMBER temp:cf:u1001_u1002 20按需取前20个，或配合SCARD做数量预检。

“推荐”不是查交集，而是交集+过滤+排序的组合动作

单纯SINTER只能回答“有哪些共同好友”，但真实推荐需要更多维度：

• 排除已发过请求的用户：维护sent_req:u1001 Set，最后用SDIFF剔除
• 按互相关注时长排序：提前用ZSET存friendship_time:u1001，再用ZINTERSTORE与SINTER结果做二次交集并按分数聚合
• 限制返回数量防拖慢：原生命令不支持LIMIT，必须在客户端截断；高频请求建议加缓存，如common_friends:u1001_u1002 TTL设为3600秒

不要试图在一个Redis命令里塞进所有逻辑——它的强项是原子交集，排序、分页、业务规则过滤交给应用层更可控，也更容易监控和降级。