Redis的HSET命令不支持为单个field设置过期时间，TTL仅作用于整个key；需通过Lua脚本原子化创建影子key并设EXPIRE来模拟field级TTL，读取时须结合EXISTS判断过期并清理。
Redis 的 HSET 命令本身不支持为单个 field 设置过期时间，这是底层设计决定的——TTL 只作用于整个 key，不是 field 级别。想实现“某个 field 过期”，必须靠外部逻辑模拟，而 Lua 脚本是目前最常用、最可控的方式。
为什么不能直接用 EXPIRE 对 field 生效
因为 Redis 的过期机制只识别 key，HGET 或 HGETALL 返回的是复合结构，内部字段没有独立的元数据空间。你对 user:1001 执行 EXPIRE user:1001 3600，整个 hash 都会在 1 小时后消失，无法保留 name 字段而让 token 字段提前淘汰。
常见错误现象包括：
- 误以为
HSET user:1001 token xxx后再执行EXPIRE user:1001:token 300能生效——实际会创建一个新 key，和原 hash 无关联 - 用两步法（
HSET+EXPIRE）在高并发下出现竞态：写入成功但过期失败，导致脏数据长期残留
EVAL 执行 Lua 脚本实现原子写入+field级TTL
核心思路是：把 field 的值和它的过期时间拆成两个 key，用脚本保证写入一致性。典型做法是为每个 field 创建一个独立的 key（如 hashkey:field），并对其设置 EXPIRE。
示例脚本（可直接 EVAL）：
local key = KEYS[1]
local field = ARGV[1]
local value = ARGV[2]
local ttl = tonumber(ARGV[3])
redis.call('HSET', key, field, value)
redis.call('SET', key .. ':' .. field, value)
redis.call('EXPIRE', key .. ':' .. field, ttl)
return 1
调用方式：
EVAL "..." 1 user:1001 token "abc123" 300
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
说明：
- 第一行写入主 hash，确保结构完整
- 第二、三行创建影子 key 并设 TTL，用于后续读取时判断是否过期
- 所有操作在服务端原子执行，不存在中间状态
读取时如何判断 field 是否已过期
单纯 HGET 拿不到过期信息，必须配合影子 key 判断。推荐封装读取逻辑：
先查 EXISTS user:1001:token，返回 0 表示已过期，此时应主动 HDEL user:1001 token 并返回空；返回 1 再执行 HGET user:1001 token。
注意点：
- 不能依赖
TTL user:1001:token的返回值做业务判断——它可能为 -2（key 不存在）或 -1（永不过期），需区分处理 - 如果业务要求强一致性，建议在写入脚本里加
DEL清理旧影子 key，避免残留 - 影子 key 名称必须唯一且可预测，否则读取端无法定位
性能与内存权衡：影子 key 方案的真实代价
每写一个 field 就多一个 key，意味着：
- 内存占用翻倍（hash 结构 + string key），尤其当 field 数量大时不可忽视
-
KEYS类命令无法跨 key 匹配，运维排查困难 - 过期 key 的被动清理由 Redis 异步执行，大量短 TTL 影子 key 可能加重 server CPU 压力
替代方案（如用 user:1001:ttl hash 存时间戳 + 客户端判断）省空间但丢原子性；选哪种，取决于你更怕内存涨还是怕逻辑错。
真正容易被忽略的是：**影子 key 的生命周期管理必须和业务语义对齐**。比如用户登录态 token 过期后，不仅该 field 要不可读，还应触发回调清理关联资源——这部分无法靠 Redis 自动完成，得在应用层补全。
