Redis EXPIRE 续期时为什么会把旧过期时间覆盖

如果一个会话 key 原来还剩 120 秒，再执行 EXPIRE session:42 1800，旧的 120 秒不会被保留，TTL 会被改成从这次命令开始重新计算的 1800 秒。这不是 Redis 丢失了过期信息，而是无条件 EXPIRE 的默认语义：为 key 设置新的过期时间。

EXPIRE 为什么会覆盖旧 TTL

Redis 给 key 保存的是一份过期时间元数据。再次调用 EXPIRE key seconds 时，命令不会把新秒数加到旧 TTL 上，而是用“当前时间 + seconds”计算一个新的过期点。于是，旧 TTL 是 120 秒还是 10 秒，都可能被新的 1800 秒覆盖。

这正是滑动过期会话的常见写法：用户每次成功访问，就把空闲窗口重置为 30 分钟。要注意它不是“最长存活 30 分钟”，而是“每次续期后最多再闲置 30 分钟”。

# 首次写入会话，并设置 30 分钟空闲窗口
redis-cli SET session:42 user-17
redis-cli EXPIRE session:42 1800

# 访问成功后无条件重置窗口；旧 TTL 会被新的 1800 秒替换
redis-cli EXPIRE session:42 1800

# 只读当前剩余秒数，不把它误当成固定到期时间
redis-cli TTL session:42

先确定你要的是哪一种续期策略

“旧过期时间被覆盖”本身不一定是故障，关键在于产品规则。固定滑动窗口允许缩短或重置；登录会话常常还需要一个绝对最长寿命，这时就不能只写无条件续期。

例如接口重试可能把一个更短的保护窗口传回来。如果业务要求“至少保留当前剩余时间”，可以使用 GT；如果业务要求“首次设置后完全不再改动”，则要用 NX，而不是误用 XX。这四种选项表达的是不同的当前过期状态边界。

# Redis 7+：只有新窗口更长时才更新，避免误把长 TTL 缩短
redis-cli EXPIRE session:42 1800 GT

# 只有 key 已经存在过期时间时才更新；XX 不等于保留旧 TTL
redis-cli EXPIRE session:42 1800 XX

# 只为没有过期时间的 key 设置 TTL
redis-cli EXPIRE session:42 1800 NX

用 TTL 和返回值定位续期异常

EXPIRE 成功设置时返回 1，条件不满足或 key 不存在时返回 0。排查时不要只看业务日志里的“已续期”，应同时记录命令返回值和续期前后的 TTL。如果 TTL 返回 -1，说明 key 仍存在但没有过期时间；返回 -2，说明 key 已经不存在。

生产检查可以按这张清单走：先确认续期使用的 key 与读取 key 完全一致；再确认设置秒数没有被单位换算成 0 或负数；随后看是否误用了 NX、XX、GT、LT；最后检查写入操作是否用 SET 覆盖了原 key，因为覆盖内容可能同时清掉过期属性。

Redis 官方文档说明，EXPIRE 的时间复杂度是 O(1)，而 NX、XX、GT、LT 选项从 Redis 7.0.0 开始提供。旧版本客户端若没有对应参数，需要升级客户端或通过服务端支持的命令方式表达，不能把客户端方法名当成 Redis 版本能力。

常见问题

EXPIRE 会把 TTL 累加吗？

不会。无条件调用会以本次 seconds 重新设置过期点，不会在旧 TTL 上做加法。

XX 能保证旧 TTL 不被覆盖吗？

不能。XX 只要求 key 已经有过期时间；条件满足后，新的 seconds 仍会替换旧 TTL。

如何实现只延长不缩短？

Redis 7 及以上使用 GT，并检查返回值；若新 TTL 不大于当前 TTL，命令不会更新。