TTL返回-2表示key不存在，-1表示key存在但永不过期；PTTL以毫秒为单位，精度更高且适用毫秒级判断场景。
为什么TTL返回-2或-1，而不是你预期的数字
这是最常被误解的起点。TTL不是“查过期时间”的万能命令——它只对**存在且带过期时间的 key** 返回非负整数；key 不存在时返回 -2；key 存在但没设过期时间（即永不过期）时返回 -1。很多人一看到 -1 就以为“出错了”，其实只是说明这个 key 是持久的。
注意：TTL 的单位是秒，向下取整，哪怕还剩 999ms，也返回 0；而 PTTL 才真正返回毫秒级精度，且不会向下取整——比如剩余 1234ms，PTTL 就返回 1234。
-
TTL在 Redis 2.8+ 对不存在的 key 统一返回-2，旧版本可能有差异，建议确认你的 Redis 版本 - 使用
EXISTS+TTL组合判断，比单看TTL返回值更可靠 - 如果 key 是通过
SET key value EX 10设置的，它一定有 TTL；但如果是SET key value后再EXPIRE失败（比如 key 被删了），TTL就会返回-2
什么时候必须用PTTL而不是TTL
当你需要毫秒级精度、或业务逻辑依赖“是否还剩 >500ms”这类细粒度判断时，TTL 的秒级截断会导致误判。例如：实现一个滑动窗口限流器，窗口长度为 600ms，用 TTL 可能刚查完还是 1 秒，下一刻就跳到 0，中间 400ms 的窗口空档无法感知。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
PTTL返回值含义与TTL完全一致，只是单位是毫秒：-2= key 不存在，-1= key 存在但永不过期 -
PTTL在 Redis 2.6+ 支持，但 2.6–2.7.9 有 bug：对刚设置PEXPIRE的 key，首次PTTL可能返回-1（实际已设过期），升级到 2.8+ 可规避 - 高并发下频繁调用
PTTL不影响性能，它和TTL一样是 O(1) 时间复杂度
PEXPIREAT 和 EXPIREAT 设置时间戳后，PTTL 返回值怎么算
PTTL 总是返回“当前时间到过期时间戳之间的毫秒差”，和你是用 PEXPIRE（相对毫秒）、EXPIRE（相对秒）还是 PEXPIREAT（绝对毫秒时间戳）设置的无关。Redis 内部统一转成毫秒级绝对时间存储，PTTL 只做减法。
- 假设现在是
1717023456789（毫秒时间戳），你执行PEXPIREAT key 1717023457789，那PTTL key立即返回1000 - 如果系统时钟被回拨（NTP 同步异常），
PTTL可能返回负数（如-123），这表示“已过期但还没被 Redis 主动删除”，此时 key 仍可读，但后续任意写操作会触发惰性删除 -
PTTL的结果不保证原子性：从执行到返回之间，key 可能刚好过期被清理，所以不能依赖单次PTTL做强一致性决策
用PTTL 做缓存预热判断时容易忽略的边界
常见做法是：查 PTTL，若 < 1000 就提前异步刷新。但这里有两个隐性坑：一是 key 可能在你判断后、刷新前被删除（比如被 LRU 清理或主动 DEL）；二是如果刷新失败，你没重试机制，下次请求又得重建，形成雪崩。
- 不要只靠
PTTL判断，应结合EXISTS或TYPE确保 key 仍存在 - 避免在业务主流程中阻塞等待刷新完成，推荐用“标记+后台任务”模式：查到
PTTL < 1000时，用SETNX refresh:xxx 1 EX 30抢锁，成功者刷新，失败者继续用旧值 -
PTTL对 Redis Cluster 中的 key 有效，但要注意 key 必须落在对应 slot，跨 slot 查询会报MOVED错误——先CLUSTER KEYSLOT key确认位置再操作
Redis 的过期时间判断本质是“快照式采样”，PTTL 提供了毫秒精度，但不提供未来承诺。真正关键的不是数值多准，而是你如何用这个数值触发下一步动作——而那一步，往往比读 TTL 更复杂。
