Redis 更新字符串值后过期时间为什么消失

Redis 用 SET 更新一个已有字符串键后，TTL 变成 -1，通常不是过期机制失效，而是因为普通 SET 会覆盖整个键，并默认丢弃原来的过期时间。需要“更新内容但沿用原倒计时”时，加上 KEEPTTL；需要每次更新都重新计算缓存时长时，则把 EX 或 PX 一起写进 SET。

先记住这条判断：TTL=-1 表示键存在但没有过期时间，TTL=-2 才表示键不存在。更新缓存前不明确过期策略，最容易把临时缓存意外变成永久键。

为什么 SET 更新后 TTL 会变成 -1

Redis 把过期时间挂在键上，但普通 SET 的语义是替换这个键保存的字符串值。官方命令文档明确说明：如果键已经存在，成功执行 SET 会覆盖旧值，同时丢弃此前关联的 TTL。于是，写入本身成功，数据内容也是新的，但这个键已经变成持久键。

下面这组命令能复现最常见的现象：

# 先写入一个 60 秒缓存，并检查剩余时间
redis-cli SET profile:42 "v1" EX 60
redis-cli TTL profile:42

# 普通 SET 只更新值，不会自动继承上一次的过期时间
redis-cli SET profile:42 "v2"
redis-cli TTL profile:42

第二次检查得到 -1，说明键还在，但原来的 60 秒倒计时已被清除。这个行为和 Redis 是否“刚好还没过期”无关，是写命令语义决定的。

先用 TTL、PTTL 和 TYPE 定位现象

排查时先确认键是否存在，再看它是什么类型以及剩余时间。TTL 返回秒，PTTL 返回毫秒；在常见 Redis 版本中，-1 表示存在但没有过期时间，-2 表示键不存在。

# 先确认类型，避免把字符串更新问题误判成其他数据结构问题
redis-cli TYPE profile:42

# 秒级检查适合人工排查，毫秒级检查适合短 TTL 或自动化测试
redis-cli TTL profile:42
redis-cli PTTL profile:42

如果客户端封装了“保存对象”的方法，还要检查它底层是否每次都发送普通 SET。很多 SDK 的过期参数是一次写入选项，不会替调用者记住上一次的 TTL。

用 KEEPTTL 保留原来的过期策略

当缓存更新只代表内容刷新，而不代表缓存应该重新获得完整寿命，可以使用 KEEPTTL：

# 创建一个还有 60 秒寿命的缓存
redis-cli SET profile:42 "v1" EX 60

# 更新值，但保留更新前仍剩下的 TTL
redis-cli SET profile:42 "v2" KEEPTTL
redis-cli TTL profile:42

KEEPTTL 保留的是执行更新那一刻的剩余时间，不会把倒计时恢复成最初的 60 秒。如果业务规则是“每次命中后重新缓存 10 分钟”，就不要用 KEEPTTL，而应明确写出新的 EX 600 或 PX。

选择关系可以这样记：

• 沿用原倒计时：SET key value KEEPTTL。
• 每次更新重置寿命：SET key value EX seconds 或 PX milliseconds。
• 先读后决定是否续期：用 TTL/PTTL 读取状态，再由业务明确选择写法。

上线前把过期策略写进更新清单

生产环境里最危险的不是偶尔出现一个 -1，而是某条更新路径长期把大量缓存变成永久键。上线前可以逐条确认：写入方法是否携带过期参数；需要保留寿命的路径是否使用了 KEEPTTL；更新后是否抽样检查 TTL；不同应用实例是否可能用不同策略覆盖同一个键。

并发场景下，先用普通 SET 写入，再单独执行 EXPIRE 还会留下短暂的无 TTL 窗口，也可能被另一条更新覆盖。若要求更新和值的过期策略一起生效，优先把 KEEPTTL 或 EX/PX 放进同一条 SET。缓存设计若还包含“滑动过期”，则应明确它是按读取续期还是按写入续期，不能把两种语义混在一个工具方法里。

相关问题

SETNX 更新后也会清除 TTL 吗？

只有条件满足并真正写入时才会改变键；排查时仍要检查客户端是否最终走了覆盖写，并在成功后读取 TTL。

KEEPTTL 会把已经没有的 TTL 恢复吗？

不会。它只保留当前已经存在的过期时间；如果键本来是持久键，仍然需要用 EX 或 PX 明确设置寿命。

TTL 为 -2 是不是 TTL 命令出错？

不是。-2 表示查询时键不存在，可能是已经过期，也可能是键名、数据库或读写实例不一致。