Redis Hash 字段过期怎么用：HEXPIRE 让会话字段单独失效

之前把 token、昵称、权限数据都放进同一个 Redis Hash 时，只要给整 key 设置 EXPIRE，整条 Hash 的所有内容就会一起失效。Redis 7.4 新增的 Hash 字段过期能力，可以把短期 token 单独设置 TTL，让稳定的资料字段继续保留；前提是你的 Redis 版本和客户端链路确实支持这组命令。

旧方案的问题：一个短期字段拖着整条 Hash 过期

假设 session:42 里同时存了登录 token、用户展示名和权限快照。token 只需保留 30 分钟，展示名却可以留存更久。旧做法通常是对 session:42 设置 key 级 TTL；到点后所有字段一起清空，下一次请求又要回业务库补齐资料。

这不是说 key 级过期不该用。整个对象的生命周期相同，例如一次性验证码或完整临时缓存，EXPIRE 依旧简单清楚。字段生命周期不一致时，才值得考虑 Hash field expiration，避免为了保留一个稳定字段拆出过多零散小 key。

HEXPIRE 的基本写法和返回结果

先写入 Hash 字段，再为需要单独过期的字段设置 TTL。官方命令格式要求在 FIELDS 后写明字段数量：

HSET session:42 token "t_abc" profile "Mina" permissions "read"
HEXPIRE session:42 1800 FIELDS 1 token
HTTL session:42 FIELDS 1 token

上面的 1800 表示 1800 秒。HEXPIRE 会为每个指定字段返回结果：1 表示 TTL 已设置或更新，0 表示条件没有满足，负数则提示字段不存在或其他特殊状态。生产代码不要只判断命令是否发出，还要把返回数组逐项校验或转换成明确的业务结果。

把 TTL 设为 0，或把绝对过期时间设到过去，会直接删除该字段。这很适合明确的失效动作，但不能把它误当成“立即刷新 TTL”。想取消字段 TTL，可使用 HPERSIST 让字段重新变为常驻。

更新 TTL 时，用条件避免把新令牌缩短

重复登录、续期任务和异步回写可能同时碰到同一个字段。HEXPIRE 提供四个互斥条件：NX 仅在字段还没有 TTL 时设置，XX 仅更新已有 TTL，GT 只接受更长的 TTL，LT 只接受更短的 TTL。

# 仅当 token 还没有 TTL 时设置 30 分钟
HEXPIRE session:42 1800 NX FIELDS 1 token

# 续期时只允许把现有 TTL 拉长
HEXPIRE session:42 1800 GT FIELDS 1 token

这里的策略要和业务语义对齐。续期接口一般更接近 GT，而后台强制下线不应依赖“把 TTL 调短”来完成权限撤销；应先清理或替换敏感字段，再让缓存过期机制完成后续收口。

兼容性和写入覆盖，是迁移时最容易漏掉的两点

HEXPIRE 从 Redis 7.4 开始可用。升级前先在目标实例执行 COMMAND INFO HEXPIRE 或检查发行版本，别让旧节点在流量切换后才报未知命令。客户端库也要核对实际版本与命令支持；遇到客户端暂未封装的情况，可以评估安全的原生命令调用，但要把参数个数和返回值解析写进测试。

另一个坑是字段被 HSET 覆盖时，字段 TTL 会被清除。也就是说，刷新 token 内容后若仍希望它 30 分钟后失效，需要在同一个业务流程里重新设置字段 TTL，并用集成测试覆盖“写入、查询 TTL、到期后读取”的完整路径。

常见问题

字段 TTL 到期后，整个 Hash 会消失吗？

不会。到期的字段会被删除，同一 Hash 中仍存在的字段继续保留；若所有字段都被删空，再根据你的数据模型决定是否还需要这个 key。

可以一次给多个字段设置相同 TTL 吗？

可以。把 FIELDS 后面的数量改为字段数量，再依次传入字段名。命令复杂度与指定字段数量相关，批量很大时要控制每次操作的规模。

为什么 HSET 后 HTTL 查不到原来的剩余时间？

官方文档说明，覆盖字段内容的 HSET 会清除该字段 TTL。写入新值后需要按业务规则重新调用 HEXPIRE。

采用前的最小检查清单

• 目标 Redis 版本支持 Hash field expiration。
• 客户端、代理和测试环境能正确发送并解析命令。
• 每个短期字段都有明确 TTL 与续期条件。
• HSET 覆盖、字段到期和字段不存在的返回结果已有测试。

Hash 字段过期解决的是“同一个对象里不同字段寿命不同”的问题。先把生命周期边界画清，再用 HEXPIRE 和 HTTL 做可验证的最小落地，比把所有缓存都改成字段 TTL 更稳。