ZSet 的 score 不能直接设为过期时间戳实现自动过期，因 Redis 不支持元素级 TTL；需业务层用时间戳排序并主动清理，推荐 Lua 脚本原子执行 zrangebyscore + zrem，避免并发误删。
zset 的 score 不能直接设为过期时间戳？
可以，但必须明确：Redis ZSet 本身不提供「元素级过期」能力，score 只是排序依据，不是内置 TTL。你把时间戳塞进 score，只是在用它做排序+筛选，真正的「失效」得靠业务主动清理或定时扫描。
zrangebyscore 拿到已过期数据后怎么安全删除？
别直接 zrem 批量删——如果并发写入同时发生，可能误删刚插入的合法数据。推荐原子操作组合：
- 用
zrangebyscore key -inf <current_timestamp> WITHSCORES</current_timestamp>查出所有过期项（注意边界用-inf，不是0，避免漏掉负时间戳） - 对返回结果做一次
zrem，但传入的是 member 列表，不是 score 范围 - 更稳妥的做法是用 Lua 脚本封装「查 + 删」，保证原子性，例如：
local members = redis.call('zrangebyscore', KEYS[1], '-inf', ARGV[1])\nredis.call('zrem', KEYS[1], unpack(members))\nreturn #members
EXPIRE 和 score 时间戳两种过期策略能混用吗？
能，但意义完全不同，容易混淆：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
EXPIRE key 3600是整个ZSet键级过期，一删全没，适合临时排行榜、活动榜单这类有明确生命周期的场景 - 把时间戳当
score是元素级逻辑过期，适合延迟队列、定时任务触发、消息重试等需要按时间精细控制的场景 - 两者叠加没实际价值——键都删了，
score再细也没用；反过来，只靠score不清理，内存会持续增长
为什么 zremrangebyscore 容易误删？
因为它是按 score 区间硬删，不校验数据有效性。比如你设 score 为 Unix 时间戳，执行 zremrangebyscore key 0 <current_timestamp></current_timestamp>，看似删过期项，但如果有人手动 zadd 了一个 score=5 的测试数据（远小于当前时间），它也会被干掉。真正可靠的判断应基于业务语义，比如「score 小于等于当前时间且状态为 pending」——而这只能靠应用层二次过滤，不能依赖纯命令。
最常被忽略的一点：Redis 不会自动帮你扫 ZSet 过期项，无论用哪种方式，清理动作必须由你发起，且要考虑并发、原子性、内存水位。别指望它像 key 的 EXPIRE 那样后台悄悄处理。
