Redis EXPIRE 与 SET EX 参数同时使用时谁决定过期时间

把 SET EX 和 EXPIRE 放在同一段写入逻辑里时，Redis 没有一个“EXPIRE 永远优先”或“SET EX 永远优先”的固定规则。成功执行的命令会按自己的语义更新 key：SET key value EX seconds 会用新的秒数建立过期时间，随后执行的 EXPIRE key seconds 会再次改写它；如果后面是普通 SET，旧 TTL 会被清掉。

判断最终过期时间只看成功命令的执行顺序和参数。最后一次真正改写过期信息的命令决定结果；需要保留原 TTL 时，使用 SET ... KEEPTTL，而不是把旧 TTL 交给调用方猜测。

官方地址：https://redis.io/docs/latest/commands/set/

本文只讨论字符串 key 的写入、覆盖和持久化边界，不把缓存续期策略、集群时钟或业务锁的完整设计混在一起。

先记住：没有固定优先级，最终状态由成功命令决定

Redis 的过期时间属于 key 的状态。SET 成功覆盖一个已有 key 时，会丢弃旧 TTL；如果命令带了 EX 或 PX，它会在同一次写入中设置新的相对过期时间。因此，先设置 EXPIRE 300，再执行 SET ... EX 60，最终大约是 60 秒；反过来先执行 SET ... EX 60，再执行 EXPIRE 300，最终大约是 300 秒。

这里的“最后”指最后一个成功改变状态的命令。若 SET ... NX 因 key 已存在而没有写入，它不会替换 value，也不会顺手改掉 TTL；不能只看代码里哪一行写在后面，还要考虑条件是否满足。

把三种写法放进同一条工作流

实际项目里可以先确定“这次写入是否应重新计时”，再选择命令。若每次写入都代表新的缓存版本，直接把 TTL 写进 SET EX，让 value 和过期时间一次更新：

SET user:42:profile "v2" EX 300
# EX 以秒为单位；成功覆盖时，旧 TTL 被新的 300 秒替换

若业务只想更新 value，不想改变已有倒计时，应使用 KEEPTTL：

SET user:42:profile "v3" KEEPTTL
# KEEPTTL 保留已有过期信息；没有旧 TTL 时仍保持持久化

若业务需要根据条件延长或缩短 TTL，再单独调用 EXPIRE，并明确使用 NX、XX、GT 或 LT。例如只在已有过期时间且新时间更长时更新：

EXPIRE user:42:profile 600 GT
# GT 只接受更长的 TTL；key 不存在或条件不满足时返回 0

同一事务里怎样避免把 TTL 写乱

如果多条命令需要一起提交，事务只能保证命令按提交顺序执行，并不会替你合并 TTL 语义。下面两种顺序的最终结果不同：

MULTI
# 先写入 60 秒，再把同一个 key 的 TTL 改成 300 秒
SET session:42 "fresh" EX 60
EXPIRE session:42 300
EXEC

如果需求是“写入后固定 300 秒”，保留一条明确的 SET EX 通常更易读；如果需求是“更新内容但沿用原倒计时”，则用 SET KEEPTTL。把普通 SET 放在 EXPIRE 后面，往往会意外把 key 变成持久化 key。

排查时可以在同一条命令流附近读取 TTL 或 PTTL：返回非负数表示仍有倒计时，-1 表示 key 存在但没有过期时间，-2 表示 key 不存在。读取结果应当结合命令是否因 NX/XX 等条件跳过来判断。

最容易误判的几个边界

还要区分秒和毫秒：EX 使用秒，PX 使用毫秒；不要把 EXPIRE 的参数当成绝对时间。若需要固定到某个时间点，应选择 EXAT 或 PXAT，并在业务层统一时钟来源。

常见问题

SET EX 和 EXPIRE 同时写时谁优先？ 没有命令级固定优先级，按成功执行顺序看最终状态，后一次改写 TTL 的命令生效。

普通 SET 为什么让 key 不再过期？ 因为成功覆盖会丢弃旧 TTL；需要更新 value 又保留倒计时，应改用 KEEPTTL。

EXPIRE 返回 0 是不是 TTL 变成永久？ 不一定。key 不存在、条件不满足或命令没有设置成功都可能返回 0，应结合 EXISTS、条件参数和当前 TTL 判断。