不是必须用 weight=0，但多数场景设为0可只保留共同存在性、避免分数量纲干扰；交集后ZSet支持常规排序操作，但需手动调用ZREVRANGE等命令；性能瓶颈主要在内存与集合规模。
zinterstore 多条件交集筛选必须用 weight=0 吗？
不是必须，但多数场景下 weight 设为 0 是为了「只保留共同存在性，忽略原始分数」。比如你有两个 ZSet：zset:paid_users（付费用户，score=1）和 zset:active_users（近7日活跃用户，score=登录次数），想取「既是付费又是活跃」的用户集合——这时你真正关心的是「是否同时在两个集合里」，而不是他们各自的 score 相加或取 min/max。
如果不设 weight，默认是 1，ZINTERSTORE 会按 sum 聚合：用户 A 在付费集里 score=1，在活跃集里 score=5，交集后 score=6。这容易造成干扰，尤其当原始 score 量纲不一致时（比如一个是布尔标记，一个是计数）。
实操建议：
- 若只需交集成员，不关心分数逻辑，显式指定
WEIGHTS 0 0+AGGREGATE SUM（此时所有结果 score 都为 0，干净） - 若要保留某一边的原始 score（比如只信任活跃度 score），用
WEIGHTS 0 1，再配AGGREGATE SUM - 避免省略
WEIGHTS参数，尤其在多 ZSet 交集时，Redis 默认全为 1，容易误叠加
ZSET 交集后还能按新分数排序吗？
可以，但得靠后续命令，ZINTERSTORE 本身只负责生成目标 key 并写入聚合后的 score，它不返回数据也不触发排序动作。生成的新 ZSet 和普通 ZSet 完全一样，支持所有标准操作。
常见误区是以为交集完就自动“重排”，其实只是把结果存进一个新 key，你要查 Top N，还得自己调 ZREVRANGE；要查某个用户的排名，得用 ZREVRANK；要加权再算一次综合分，得用 ZINCRBY 或脚本批量更新。
举个典型电商场景：你有三个 ZSet：zset:sales（销量）、zset:rating（好评率×100）、zset:hot（点击热度）。先 ZINTERSTORE zset:candidate 3 zset:sales zset:rating zset:hot WEIGHTS 0.4 0.4 0.2 AGGREGATE SUM，得到候选商品集；再对 zset:candidate 执行 ZREVRANGE zset:candidate 0 49 WITHSCORES 拿前 50 名。
注意：ZINTERSTORE 会直接覆盖目标 key 的旧数据，如果这个 key 正被其他服务读取，可能造成短暂不一致——建议用带时间戳的 key 名（如 zset:rank:20261020），再原子切换 alias。
为什么 zinterstore 结果里 member 顺序看起来不对？
不是顺序不对，是 Redis 严格按 score 升序排，而你看到的“乱序”往往来自两个原因：score 相同 + member 字典序生效，或者你用了 ZRANGE（升序）却期望看 Top N（该用 ZREVRANGE）。
比如交集后多个商品 score 都是 0（因为你用了 WEIGHTS 0 0），那它们就按 member（通常是商品 ID）字典序排列："1001"、"1002"、"2001"……如果你希望同分时按上架时间先后排，ZSet 本身不支持自定义第二排序维度，得把时间戳编码进 member，例如 "1001_1734682200"（ID_时间戳），这样字典序就等价于时间序。
另一个坑：ZSet 的 score 是 double 类型，浮点精度问题可能导致本该相等的分数实际不等（比如 0.1+0.2 ≠ 0.3）。电商榜单强烈建议用整数 score，或把小数转成整数存储（如好评率 × 100 存为整数）。
实操建议：
- 查交集结果时，明确用
ZREVRANGE key 0 99 WITHSCORES看高分在前 - 避免在 score 中混用不同量纲数值（销量 vs 评分 vs 时间戳），要么归一化，要么拆成多阶段计算
- member 尽量用定长、可排序字符串，别用 UUID 这类无序值
zinterstore 性能瓶颈在哪？
主要卡在内存和网络开销，不是 CPU。ZSet 交集是 O(N×M) 复杂度（N 是最小集合基数，M 是参与集合数），Redis 会把所有输入 ZSet 全量加载进内存做哈希匹配。当单个 ZSet 有千万级元素，又参与三四个集合交集时，很容易触发慢日志甚至 OOM。
真实电商场景中，更稳妥的做法是「预过滤 + 小集合交集」：先用 HyperLogLog 或布隆过滤器快速筛掉明显不满足条件的大流量用户（比如非付费用户直接 pass），再把剩余几千人 ID 拉出来，用 ZADD 写入临时 ZSet，最后拿这个小集合去交集。
另外，ZINTERSTORE 不支持 limit，不能像 ZRANGEBYSCORE 那样只取 top K 参与运算。所以如果只是为了拿交集 Top 100，不要先交完整个大集合再截断，而是考虑用 Lua 脚本 + ZRANGE 分批拉取、本地合并。
一句话收尾：ZSet 交并集不是万能胶，它适合中等规模、维度稳定、结果可缓存的榜单场景；一旦集合基数超过 500 万，就得警惕内存毛刺和主从同步延迟，这时候该上 ClickHouse 做离线宽表，不该硬扛。
