Redis EXPIRE 条件参数如何避免覆盖更长 TTL

缓存刷新最容易踩的坑，是每次拿到数据都直接执行 EXPIRE cache:user:42 300。如果这个 key 原来还剩 1800 秒，这条命令会把生命周期改成 300 秒，长缓存就被短缓存覆盖了。

解决思路不是在客户端先读 TTL 再判断，而是把判断条件交给 Redis：首次设置用 NX，只处理已经有过期时间的 key 用 XX，只允许变长用 GT，只允许变短用 LT。官方地址：https://redis.io/docs/latest/commands/expire/

如果业务规则是“刷新不能缩短已有缓存”，优先选择 EXPIRE key seconds GT；如果规则是“没有 TTL 才补上”，选择 NX。

普通 EXPIRE 为什么会覆盖旧 TTL

EXPIRE 的默认行为是直接设置新的秒数。它不关心旧 TTL 是更长还是更短，所以“写入缓存”和“更新缓存策略”混在一起时，调用方很容易把长生命周期误改短。

# 中文说明：先写入一个 key，再设置较长的初始 TTL
redis-cli SET cache:user:42 "profile-v1"
redis-cli EXPIRE cache:user:42 1800

# 中文说明：无条件 EXPIRE 会直接替换剩余时间，可能缩短缓存寿命
redis-cli EXPIRE cache:user:42 300

# 中文说明：TTL 返回剩余秒数，-1 表示没有过期时间，-2 表示 key 不存在
redis-cli TTL cache:user:42

这里的关键不是命令复杂，而是更新动作缺少“允许覆盖”的边界。只要多个业务路径都可能刷新同一个 key，就应该把 TTL 的比较规则写进命令。

四种条件参数分别保护什么

四个参数互斥，一次 EXPIRE 只选择一个。可以先把业务句子翻译成下面的判断：

例如登录态续期通常不希望被一次短请求缩短，可以使用 GT：

# 中文说明：只有新 TTL 1800 大于当前 TTL 时才更新
redis-cli EXPIRE cache:user:42 1800 GT

# 中文说明：返回 1 表示条件满足并完成设置，返回 0 表示没有修改
redis-cli TTL cache:user:42

要注意一个边界：没有过期时间的 key 对 GT 会被当作无限 TTL，因此不会被 GT 设置；而 LT 把无过期 key 视为无限 TTL，所以可以用来给持久 key 补一个有限 TTL。

用 redis-cli 与 Go 客户端表达条件

命令行调试时，直接把条件写在秒数后面即可。应用代码中也要保留同样的语义，不要先用 TTL 做一次读取、再在客户端决定是否调用普通 EXPIRE，否则并发刷新之间会出现竞态窗口。

# 中文说明：首次没有过期时间才设置 600 秒
redis-cli EXPIRE cache:user:42 600 NX

# 中文说明：只有已有 TTL 且新值更长时才延长到 3600 秒
redis-cli EXPIRE cache:user:42 3600 GT

# 中文说明：只有已有 TTL 且新值更短时才缩短到 60 秒
redis-cli EXPIRE cache:user:42 60 LT

package main

import (
    "context"
    "fmt"
    "time"

    "github.com/redis/go-redis/v9"
)

func refreshLonger(ctx context.Context, rdb *redis.Client, key string) error {
    // 中文说明：ExpireGT 把“只能延长”交给 Redis，避免客户端读写竞态。
    changed, err := rdb.ExpireGT(ctx, key, 30*time.Minute).Result()
    if err != nil {
        return err
    }
    // 中文说明：false 可能表示 key 不存在，或新 TTL 没有大于当前 TTL。
    fmt.Println("ttl updated:", changed)
    return nil
}

func main() {
    // 中文说明：示例只展示客户端调用形状，实际项目应复用已有连接配置。
    rdb := redis.NewClient(&redis.Options{Addr: "127.0.0.1:6379"})
    defer rdb.Close()
    _ = refreshLonger(context.Background(), rdb, "cache:user:42")
}

用返回值与 TTL 做复查

条件命令返回 1 或 0。返回 0 不等于 Redis 出错，可能是 key 不存在，也可能是条件不满足。复查时把返回值和 TTL 放在一起看：

# 中文说明：先读取目标 key 的当前 TTL，确认它是否存在且是否已有过期时间
redis-cli TTL cache:user:42

# 中文说明：只在新 TTL 更长时延长，返回 0 时保留原 TTL
redis-cli EXPIRE cache:user:42 3600 GT

# 中文说明：再次读取 TTL，判断是否发生更新；不要把示例输出当作固定值
redis-cli TTL cache:user:42

排查时可按三种情况处理：TTL=-2 表示 key 已不存在；TTL=-1 表示 key 存在但没有过期时间；正数表示已有 TTL。普通更新还要留意 SET 这类覆盖 key 内容的命令可能清除原有过期时间，若要保留 TTL，应在写入策略中单独处理。

常见问题

NX 和 GT 可以一起使用吗？
不可以，四个条件参数互斥。需要“没有 TTL 才设置”用 NX，需要“新 TTL 更长才设置”用 GT。

为什么 EXPIRE 返回 0？
可能是 key 不存在，也可能是 NX、XX、GT 或 LT 的条件没有满足。用 TTL 区分状态，不要直接当成网络错误。

只想延长缓存，为什么不用先 TTL 再比较？
并发刷新时，先读后写不是一个原子判断。直接使用 GT 能把比较和设置放在 Redis 命令内部。