Redis TTL 为什么没有按预期过期

Redis TTL 没有按预期过期时，先不要把原因归到“Redis 定时器不准”。大多数问题集中在三处：过期时间根本没有设置成功，后续的覆盖写清除了 TTL，或者观察方式把“已到期”和“已经从键空间删除”混成了一件事。

官方文档：https://redis.io/docs/latest/commands/expire/

排查顺序应当是：先看 TTL/PTTL 返回值，再确认 EXPIRE 的返回值和写入顺序，最后区分覆盖写、原地修改、惰性删除与主动删除。只要某一步的证据对不上，就先修这一层。

先用 TTL 判断问题属于哪一类

对同一个键连续执行下面的命令。这里的重点不是等待它自然消失，而是先确认 Redis 当前保存的过期元数据。

redis-cli SET session:42 "ready"
redis-cli EXPIRE session:42 60
redis-cli TTL session:42
redis-cli PTTL session:42
redis-cli EXISTS session:42

# TTL 返回非负整数：仍有过期时间；PTTL 返回毫秒级剩余时间
# TTL 返回 -1：键存在，但没有关联过期时间
# TTL 返回 -2：键已经不存在，不能再把它当作“TTL 没生效”

TTL 以秒返回剩余时间，PTTL 以毫秒返回。看到 -1 时，优先检查是否有一次后续 SET、GETSET 或存储类命令覆盖了值；看到 -2 时，说明键已不存在，应回到写入链路查找是否提前删除或已过期。

确认 EXPIRE 真的作用在目标键上

EXPIRE 只能给已经存在的键设置超时；返回 1 才代表设置成功，返回 0 往往意味着键不存在，或者 NX、XX、GT、LT 条件没有满足。常见的错误顺序是先调用 EXPIRE，随后才 SET，结果过期命令没有作用。

redis-cli DEL cache:user:42
redis-cli EXPIRE cache:user:42 30
# 返回 0：键还没有创建，EXPIRE 没有设置任何过期时间
redis-cli SET cache:user:42 "ready"
redis-cli TTL cache:user:42
# 返回 -1：SET 创建了一个持久键

redis-cli SET cache:user:42 "ready"
redis-cli EXPIRE cache:user:42 30
# 返回 1：当前键已经拥有 30 秒过期时间

如果业务使用的是带条件的过期命令，也要把返回值写入日志或指标。比如 EXPIRE key 30 XX 要求键已经存在且已有过期时间；它返回 0 时，不能继续假设 TTL 已经更新。

重点检查：覆盖写会清除 TTL

Redis 会把键的值和过期时间视为两个相关但不同的属性。SET、GETSET、DEL 以及各种 *STORE 命令会替换或删除内容，因此会清掉原来的 TTL；INCR、LPUSH、HSET 这类只修改已有值结构的操作则会保留 TTL。

redis-cli SET profile:42 "v1"
redis-cli EXPIRE profile:42 120
redis-cli HSET profile:42 name "alice"
# 下面是示意：对 Hash 使用 HSET 时，原有 TTL 会保留

redis-cli SET profile:42 "v2"
redis-cli TTL profile:42
# 返回 -1：SET 覆盖整个值，同时清除了过期时间

工程上最稳妥的写法是把值和过期时间放进同一个写入意图里，避免“缓存更新函数”在别处又调用一次不带过期参数的 SET。以 go-redis 为例，可以让设置值和过期时长由同一次调用表达：

ctx := context.Background()
// Set 同时提交值和过期时长，避免后续覆盖写遗漏 EXPIRE。
if err := client.Set(ctx, "cache:user:42", "ready", 30*time.Second).Err(); err != nil {
    // 保留原始错误，便于区分连接失败和业务写入失败。
    return err
}
// 读取 TTL 只用于排查或观测，不要把它当作精确的业务计时器。
ttl, err := client.TTL(ctx, "cache:user:42").Result()
if err != nil {
    return err
}
log.Printf("cache ttl=%s", ttl)

惰性删除和主动删除是两条路径

Redis 官方文档把过期处理分为被动和主动两种方式。客户端访问一个已经到期的键时，Redis 会在这次访问路径上把它删除；对于永远不会再被访问的过期键，Redis 会周期性从带过期时间的键中抽样，主动清理已经到期的条目。

因此，“TTL 已经到期”和“立刻能在所有观测中看到键消失”不是完全相同的判断。不要用固定的毫秒数去推断后台抽样清理的精确时刻；如果业务需要可靠地知道缓存是否可用，应以读操作返回的不存在状态为准，并在写入端保证每次重建缓存都重新表达过期策略。

上线前用一张清单收口

最后再检查连接配置中的数据库编号、集群路由和键名拼接。很多“TTL 不生效”其实是写入端和读取端没有访问同一个逻辑键。把 EXPIRE 返回值、设置时刻、目标键名和实例标识一起记录下来，通常就能把问题从“感觉没有过期”收敛到一条具体写入路径。

常见问题

为什么 TTL 会从正数突然变成 -1？

最常见原因是后续执行了不带过期参数的 SET 或其他覆盖写。检查所有更新同名键的代码路径，而不只看第一次写入。

EXPIRE 成功后能保证到点立刻收到删除事件吗？

不能把它理解为精确的定时器。访问过期键会触发被动删除，未访问的键由 Redis 的主动过期机制处理；业务判断应以读取结果和自身的失效策略为准。