Redis Hash 不支持字段级过期，仅整个 key 可设 TTL；需 per-field 过期时应改用带 EX 的 String 或 ZSET 辅助实现，因原生不支持是出于内存模型与性能权衡。
Redis Hash 本身不支持设置过期时间
这是最常被误解的一点：你不能对 HSET、HMSET 或整个 Hash 结构直接调用 EXPIRE 以外的方式设过期——但关键在于，EXPIRE 是作用于 key 级别的，不是 field 级别。也就是说，只有整个 Hash key 可以有过期时间，它的任意单个 field 都无法独立过期。
常见错误现象包括：试图用 HEXPIRE（不存在）、在 HSET 后对某个 field 调 EXPIRE（无效）、或误以为 HMSET 支持过期参数（它不支持）。
- Hash 的过期只能通过给 key 设置 TTL 实现，例如：
EXPIRE user:1001 3600 - 一旦 key 过期，整个 Hash（含所有 field）都会被删除
- 如果业务需要“每个 field 不同过期时间”，必须换结构或加层逻辑
替代方案：用 String 模拟带过期的 Hash 字段
当确实需要 per-field 过期能力时，最直接的做法是放弃 Hash，改用多个带独立过期时间的 String key。比如把 user:1001 的 email 和 avatar 分别存为：
SET user:1001:email "a@b.com" EX 3600 SET user:1001:avatar "/img/1.png" EX 86400
这种做法牺牲了原子性（无法一次读取全部字段），但换来精确控制。注意路径命名要统一、可预测，否则后续维护成本高。
- 适合字段数量少、更新不频繁、且过期策略差异大的场景
- 避免用
user:1001_email这类下划线分隔，推荐冒号更符合 Redis 命名惯例 - 批量读取可用
MGET user:1001:email user:1001:avatar，但写入无法原子
用 Sorted Set + 定时任务模拟 Hash 字段级 TTL
如果既要保留 Hash 的聚合语义，又要支持字段级过期，可以引入辅助结构：用 ZSET 记录每个 field 的过期时间戳，再配合外部定时任务（如 Python 的 APScheduler 或 Redis 的 KEYSPACE NOTIFICATIONS）清理过期项。
例如：
ZADD user:1001:expires 1717023600 email ZADD user:1001:expires 1717030800 avatar
然后程序在读取 HGET user:1001 email 前，先查 ZSCORE user:1001:expires email 并比对当前时间。过期则删掉该 field（HDEL）并返回空。
- 性能开销明显：每次读都要多一次 ZSCORE 查询
- 需要处理时钟漂移问题，建议用服务端时间（如
TIME命令）而非客户端本地时间 - 不适用于高并发低延迟场景；更适合后台任务驱动型业务
为什么 Redis 不原生支持 Hash 字段过期？
这不是设计疏漏，而是权衡结果。Redis 的内存模型基于 key-value，每个 key 对应一个 redisObject，而 Hash 是内部编码为 ziplist 或 hashtable 的复合结构。若为每个 field 单独维护 TTL，会显著增加内存碎片和元数据开销，也破坏了 O(1) 查找的确定性。
换句话说：字段级过期本质上是「状态+时间」的二维管理，这已经超出 Redis 作为纯内存 KV 存储的定位。官方明确表示暂无计划支持 HEXPIRE 类命令。
真正容易被忽略的是：很多团队在早期没想清楚数据生命周期，硬用 Hash 存混合生命周期字段，后期才发现迁移成本远高于初期选型成本。
