Redis 7.4 首次原生支持哈希字段级过期，新增 HPEXPIRE（秒级）和 HPEXPIREAT（秒级时间戳）命令，可为单个 field 设置独立 TTL 并原子删除，不干扰整个 hash 的过期状态。
Redis 7.4 新增 HPEXPIRE 和 HPEXPIREAT 命令
Redis 7.4 是首个原生支持 Hash 字段级过期的正式版本。在此之前，HSET、HINCRBY 等操作不会影响整个 key 的 TTL，更无法为单个 field 设置独立过期时间——这是底层设计决定的：Redis 的 expires 字典只记录 key 级别的时间戳，不感知内部结构。
7.4 引入了两个新命令：
-
HPEXPIRE key field seconds：为指定 field 设置相对过期时间（秒） -
HPEXPIREAT key field timestamp：为指定 field 设置绝对过期时间戳（秒）
注意：HPEXPIRE 不会重置整个 hash key 的 TTL；它只管理该 field 的生命周期，且过期后该 field 被原子删除（HGET 返回 nil，HLEN 减 1）。底层实现依赖新增的字段元数据存储结构，与原有 expires 字典分离。
旧版本（≤7.2）必须绕开 Hash 结构本身
在 7.4 之前，所有变通方案本质都是“用其他数据结构模拟字段过期”，没有银弹。常见做法有：
- 把每个 field 拆成独立的 string key，用
SETEX或EXPIRE控制生命周期，再用业务层做聚合。缺点是 key 数量爆炸，KEYS扫描不可控，内存碎片加剧 - 用一个 string key 存整个 hash 的 JSON，再配合定时任务或发布订阅 + Lua 脚本定期清理过期字段。但 JSON 解析开销大，且无法原子更新单个 field
- 在 value 中嵌入逻辑过期时间（如
{"value":"xxx","expireAt":1716680000}），每次HGET后由客户端判断并主动忽略过期字段。问题在于：业务强耦合、无法被 Redis 内存淘汰策略识别、HLEN统计不准
这些方法都绕不开一个事实：旧版 Redis 对 Hash 字段的过期支持是零。任何“伪实现”都会在原子性、一致性或运维成本上打折扣。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
升级到 7.4 后仍需注意的兼容性陷阱
即使你已部署 7.4，直接使用 HPEXPIRE 也不等于万事大吉：
- 客户端驱动可能尚未适配新命令，比如 Jedis 4.4+、Lettuce 6.3+ 才提供封装，老版本调用
sendCommand易出错 -
HPEXPIRE不支持 pipeline 批量设置多个 field 过期（目前单次只接受一个 field），高频写场景需权衡网络往返开销 - 监控工具（如 Prometheus exporter）默认不采集字段级过期指标，需自行扩展
INFO keyspace解析逻辑 - 备份恢复时，RDB/AOF 中字段过期信息被完整保存，但主从同步延迟可能导致从节点字段过期时间短暂漂移（毫秒级，通常可忽略）
Hash 字段过期不是万能的，别滥用
字段级过期解决了“部分数据要早死”的需求，但它没改变 Hash 本身的内存模型：每个 field 仍共享同一个 key 的 dictEntry 开销，且过期字段删除后不会立即归还内存（需等 next rehash）。
真正该优先考虑字段过期的场景其实很窄：
- 用户 session 中的临时 token 字段（如
refresh_token需 7 天过期，而access_token只需 2 小时） - 商品 SKU 层级的动态价格缓存，不同渠道价有效期不同
- 配置中心中，某些灰度开关字段需要比主配置更短的生效窗口
如果只是想让整个 hash “整体过期”，继续用 EXPIRE 更轻量；如果字段间过期策略差异不大，硬拆成多个 key 反而更清晰。字段过期能力上线后，最容易被忽略的一点是：它让数据生命周期变得更细、更难追踪——调试时你得同时查 TTL 和 HPTEL，而不是只看一个值。
