Redis原生SINTER不支持带权重或条件过滤的交集计算，因其仅做纯元素匹配；需用Lua脚本在服务端原子执行复杂逻辑，但须防范阻塞、性能与维护风险。
Redis原生SINTER为什么不能直接处理带权重或条件过滤的集合交集
Redis 的 SINTER 只能对多个 SET 做纯元素匹配，返回共同存在的成员。它不支持：按分数筛选（比如只取 zset 中 score > 100 的成员）、保留原始 score、合并时加权计数、或对每个交集元素执行自定义判断（如字符串前缀匹配）。一旦需求超出“存在即交集”，就必须绕过原生命令。
用 Lua 脚本在服务端一次性完成带逻辑的交集计算
Lua 脚本在 Redis 中原子执行，避免网络往返和中间状态，是实现复杂交集最稳妥的方式。关键点在于：把参与计算的数据提前加载进 Lua 环境（通过 KEYS 和 ARGV），再用 Lua 原生数据结构（table）做二次加工。
- 所有输入 key 必须通过
KEYS传入，不能硬编码；否则脚本无法被 Redis Cluster 路由 - 如果涉及
ZSET，用redis.call("ZRANGEBYSCORE", KEYS[i], "-inf", "+inf", "WITHSCORES")拉取完整数据，别用ZRANGE（默认不含 score） - 交集逻辑写在 Lua 里：例如用两个 table 记录各集合的成员 → 遍历小表查大表 → 满足条件才 push 到结果表
- 最终用
return返回结果数组，Redis 自动转为客户端响应
示例：求两个 zset 的交集，但只保留 score 均 ≥ 50 的成员，并返回其平均 score：
local set1 = redis.call("ZRANGEBYSCORE", KEYS[1], 50, "+inf", "WITHSCORES")
local set2 = redis.call("ZRANGEBYSCORE", KEYS[2], 50, "+inf", "WITHSCORES")
local members = {}
local seen = {}
for i = 1, #set1, 2 do
local m = set1[i]
seen[m] = {s1=set1[i+1]}
end
for i = 1, #set2, 2 do
local m = set2[i]
if seen[m] then
table.insert(members, m)
table.insert(members, tostring((seen[m].s1 + set2[i+1]) / 2))
end
end
return members
性能与内存风险：什么时候不该用 Lua 做交集
Lua 脚本运行时会阻塞 Redis 单线程，若处理的数据量过大（例如单个 zset 超 10 万成员），会导致其他命令长时间等待。这不是“慢”，而是“卡”。
- 用
redis.call("SCARD", key)或ZCARD在脚本开头预检大小，超阈值（如 5000）直接return error - 避免在 Lua 中做嵌套循环遍历大数据集；优先用 Redis 原生命令预过滤（如先
ZREMRANGEBYSCORE清理无效数据） - 如果交集逻辑需频繁变更，Lua 脚本不易维护——此时应考虑把数据导出到应用层计算，Redis 仅作缓存
调试 Lua 脚本交集逻辑的三个实操技巧
Redis 不提供 Lua 断点调试，出错只能靠日志和分段验证。
- 本地用
redis-cli --eval测试脚本，配合print()输出中间变量（注意：生产环境禁用print，它会写到 Redis 日志且影响性能） - 把复杂逻辑拆成多个小脚本：先用
SMEMBERS+ZRANGE导出样本数据，在本地 Lua 环境跑通逻辑，再移植进 Redis - 错误信息如
(error) ERR Error running script (call to f_...): @user_script:xx: ...中的行号是真实 Lua 行号，但要注意：redis.call 抛异常时不会显示具体参数值，需手动补 log
真正难的不是写对脚本，而是判断该不该让它承担这个计算——数据规模、变更频率、一致性要求，三者缺一都会让 Lua 方案从“简洁”变成“隐患”。
