ZREMRANGEBYSCORE 清不掉过期 ZSet 数据，根本原因是 Redis 的 ZSET 不自动感知过期，需用时间戳作 score 并手动按时间范围删除。
为什么 ZREMRANGEBYSCORE 清不掉过期的 ZSet 数据？
根本原因不是命令用错了，而是时间戳没对齐。Redis 的 ZSET 本身不自动感知“过期”，你得自己把“过期”定义成一个分数范围——比如用 Unix 时间戳当 score，过期就是 score 。如果存进去的 score 是毫秒时间戳，但清理时用的是秒级 time.time()，那大概率漏删。
- 确认写入时用的是秒还是毫秒：查一条数据，执行
ZRANGE key 0 0 WITHSCORES看 score 值量级（10 位是秒，13 位是毫秒） - 清理前先算准当前时间戳单位，Python 里
int(time.time())是秒，int(time.time() * 1000)是毫秒 - 别用
0当下界——万一有人手动塞了负分，ZREMRANGEBYSCORE key -inf (now)才安全
用 ZREMRANGEBYSCORE 清理排行榜历史数据的正确姿势
排行榜场景常见“只保留最近 7 天活跃用户”，这时 score 应该是最后活跃时间戳。清理不是删全量，而是切片删——一次别删太多，避免阻塞主线程。
- 命令格式固定：
ZREMRANGEBYSCORE key -inf (timestamp)，括号表示开区间，(timestamp)表示“严格小于 timestamp” - 建议每次最多删 1000 条：先
ZCOUNT key -inf (timestamp)预估数量，超了就分批，用ZREMRANGEBYSCORE key -inf (timestamp) LIMIT 0 1000（注意：LIMIT 在 Redis 7.0+ 才支持，旧版本只能靠客户端循环） - 别在高峰期直接跑全量清理——加个
SCAN式渐进清理逻辑，或改用后台任务轮询
ZREMRANGEBYSCORE 和 EXPIRE 能不能一起用？
不能混用目标。Redis 的 EXPIRE 是 key 级过期，对 ZSET 整体生效；而 ZREMRANGEBYSCORE 是成员级清理。你要的是“榜单里的人过期就下榜”，不是“整个榜单消失”。给 ZSet 设 EXPIRE 只会让整个结构被删，和业务逻辑冲突。
- ZSet 本身不支持成员级 TTL，所以必须靠 score 模拟
- 如果真需要某几个成员单独过期，得拆成多个小 ZSet，按周期命名（如
rank:20240501），再配合定时DEL - 混合用
EXPIRE+ZREMRANGEBYSCORE容易误删——比如 key 刚被EXPIRE标记，还没到时间就被ZREMRANGEBYSCORE清空，结果啥都没留下
Python 里调用 ZREMRANGEBYSCORE 的典型错误
用 redis-py 时，最容易栽在参数类型和返回值解读上。它不报错，但返回 0 却以为删成功了。
-
zremrangebyscore('myzset', '-inf', '(1717027200)')—— 字符串传参没问题，但括号必须是字符串一部分，不能靠 Python 拼接，否则变成'(1717027200)'被当字面量解析 - 返回值是删除的成员数，不是布尔值：返回
0可能是真没数据，也可能是 score 范围写反了（比如写成(now) +inf） - 用 pipeline 批量操作时，记得
execute()后检查每个命令返回值，别只看最后一个
实际清理时最麻烦的从来不是命令怎么写，而是 score 的语义是否和业务生命周期对齐——比如“最后登录时间”和“最后付费时间”混在一个 ZSet 里，一删就全垮。这事没法靠工具解决，得在写入时就约定清楚。
