Redis TTL 返回 -1 和 -2 分别代表什么

排查 Redis 缓存时，TTL key 返回负数并不只有一种含义：-1 表示键存在，但没有设置过期时间；-2 表示键不存在。返回大于等于 0 的数，才是“键存在且还剩这么多秒”，其中 0 只代表已经进入最后一秒附近，不代表键不存在。

Redis TTL 的 -1、-2 到底对应什么状态

Redis 官方 TTL 命令返回键的剩余生存时间，单位是秒，时间复杂度为 O(1)。它有三个需要记住的结果区间：

所以，TTL 的负数是有明确语义的协议结果，不是 Redis “没有返回数据”。如果只把所有负数归为“缓存失效”，就会漏掉永久键逐渐堆积的问题。

用三组命令复现 TTL 的返回值

可以在测试库中构造三个互不相同的键。下面的命令只演示状态，不依赖业务数据：

# 清理本示例使用的键，避免上一次实验干扰结果
redis-cli DEL demo:ttl:finite demo:ttl:permanent demo:ttl:missing

# 有限期键：EX 直接在 SET 时写入过期时间
redis-cli SET demo:ttl:finite "v1" EX 60
redis-cli TTL demo:ttl:finite

# 永久键：普通 SET 没有附带过期时间
redis-cli SET demo:ttl:permanent "v2"
redis-cli TTL demo:ttl:permanent

# 缺失键：查询不存在的名字
redis-cli TTL demo:ttl:missing

# 用 EXISTS 验证 -1 与 -2 的差异
redis-cli EXISTS demo:ttl:permanent demo:ttl:missing

预期会看到有限期键返回接近 60 的正数，永久键返回 -1，缺失键返回 -2。正数会继续递减；执行 TTL 的时间不同，具体数值不应被当成固定常量。

如果一个本应有 TTL 的键返回 -1，优先查看写入代码是否把两步操作写成了先 SET、后 EXPIRE，以及之后是否又执行了不带过期参数的 SET。如果返回 -2，再核对完整键名、连接的逻辑数据库和查询发生的时间点。

业务代码如何分别处理 -1 和 -2

程序里最容易出现的错误是只判断“TTL 小于 0”。更稳妥的做法是把三个状态显式建模。以 Go 客户端为例，下面的逻辑只负责解释 Redis 返回值，不把网络错误伪装成键缺失：

// classifyTTL 把 Redis TTL 的协议结果转换成业务可读状态。
func classifyTTL(ttl int64, err error) (string, error) {
	if err != nil {
		// 网络、超时或权限错误不能当成 -2，否则会误触发回源。
		return "", err
	}
	switch {
	case ttl == -2:
		return "missing", nil // 键不存在：可考虑回源或重新写入
	case ttl == -1:
		return "permanent", nil // 键存在但无 TTL：进入配置排查
	case ttl >= 0:
		return "expiring", nil // 键存在且在倒计时
	default:
		return "unknown", nil // 为未来的协议变化保留安全分支
	}
}

缓存回源通常只对 missing 做；permanent 则更适合记录告警或抽样检查。若业务确实允许永久缓存，应该在配置或命名约定中明确，而不是让 -1 静默出现。

为什么刚设置过期时间，TTL 仍然可能是 -1

这类现象通常不是 TTL 自己失效，而是写入链路改变了键的过期元数据。常见情况有三种：

• 后续普通 SET 覆盖：同一个键再次执行不带 EX/ PX 的 SET，可能让键变成无过期状态。应统一封装写缓存操作，避免调用方自行拼命令。
• 先写后过期的窗口：先 SET 再 EXPIRE 不是一个原子动作，中间失败会留下永久键。能在 SET 时使用 EX 或 PX，就不要把过期时间作为事后补丁。
• 查询上下文不一致：应用连接的 DB、集群节点或键前缀与排查命令不一致时，看到的 -2 可能只是查了另一把“同名不同处”的键。

另外，TTL 的单位是秒；需要更细粒度时使用 PTTL，但它的 -1 和 -2 语义仍然分别表示无过期时间和键不存在。这里先别急着给永久键统一补 TTL，先确认它是不是业务刻意保留的配置数据。

常见问题

TTL 返回 0 是不是键已经不存在？

不是。0 表示键仍可能存在，但剩余时间已经小于约一秒；是否能读到值取决于你下一次命令执行的时机。

Redis TTL 返回 -1 应该立刻删除键吗？

不应该直接删除。先确认该键是否本来就设计为永久配置或版本标记；只有确定它应当过期时，才修正写入链路或补充过期策略。

TTL 返回 -2 一定是业务没有写入吗？

不一定。键可能已经自然过期，也可能键名、逻辑数据库、集群路由或查询时机不一致，需要结合写入日志和 EXISTS 一起判断。

记住这条判断式即可：-1 = 键在，但没有过期时间；-2 = 键不在；非负数 = 键在，并且还在倒计时。把三种状态分开后，缓存回源、永久键排查和过期策略修复就不会互相混淆。