应优先使用支持TTL的单命令如Set(key,value,ttl)一步设值与过期，避免HMSET+EXPIRE两步导致的TTL丢失；Expire仅作补救，需校验返回值；操作须加context超时；监听过期事件需配置notify-keyspace-events并注意DB编号。
用 Set 一步到位设 key + TTL，别先 HMSET 再 EXPIRE
Go 操作 Redis 时最常踩的坑，就是把「存数据」和「设过期」拆成两步。比如先用 HMSET 存结构体，再补一句 EXPIRE —— 这在高并发下极可能丢 TTL：第二步失败，key 就永久滞留内存。
正确做法是直接用支持 TTL 的写入命令，一气呵成：
-
Set(key, value, ttl)：最常用，value 是字符串或序列化后的字节 -
SetNX(key, value, ttl)：带条件的设值（仅 key 不存在时生效），适合分布式锁 -
HSet(key, field, value)不支持 TTL；想给整个 hash 设过期，必须用Set存序列化后的 map，或改用HSet+ 单独Expire（但得加错误重试）
示例：
err := rdb.Set(ctx, "user:1001", `{"name":"alice","role":"admin"}`, 30*time.Minute).Err()
Expire 是补救手段，不是首选方案
当你已经存了 key，又临时需要加过期时间，才用 Expire。它本质是“事后补票”，有竞态风险：如果 key 刚被删、又被其他 goroutine 新建，Expire 就会失效或误操作。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
Expire(key, ttl)返回bool：true 表示成功设置了过期时间，false 表示 key 不存在或已过期 - 别忽略返回值 —— 很多人写了
Expire却没检查err或返回布尔值，导致以为设上了，其实没生效 - 若 key 是 hash、list 等复合类型，
Expire作用于整个 key，不是某个 field
查 TTL 值验证是否设成功：
ttl, err := rdb.TTL(ctx, "user:1001").Result()
if err != nil || ttl == -1 {
log.Printf("key 无 TTL 或不存在")
}
用 context.WithTimeout 防止 Set/Expire 卡死，尤其在云 Redis 场景
Redis 网络抖动或慢查询时，Set 或 Expire 可能阻塞数秒甚至更久。生产环境不加超时，一次故障就能拖垮整条请求链路。
- 永远别用全局
context.Background()调用 Redis 命令 - 为每个操作配独立 context，例如：
ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond) - 超时后
cancel()，避免 goroutine 泄漏 - 云厂商 Redis（如阿里云、腾讯云）对单命令响应时间敏感，超时设置建议 ≤ 800ms
监听 key 过期事件？小心频道名和 DB 配置
Redis 的过期事件不是实时广播，而是通过 Pub/Sub 发布到特定频道，且默认关闭 —— 很多人照着代码抄完，发现根本收不到 expired 消息。
- 必须提前在
redis.conf中开启：notify-keyspace-events Ex（或AKE） - 频道名严格绑定 DB 编号，比如监听 DB 0 的过期事件，频道是
__keyevent@0__:expired；DB 1 就是@1__，不能写错 -
PSubscribe是长连接，需另起 goroutine 处理消息，主流程别等它 - 事件只通知 key 名，不带 value —— 想知道过期前的值，得在 Set 时自己存一份日志或用 Lua 原子读取
监听代码关键行：
rdb.PSubscribe(ctx, "__keyevent@0__:expired")
真正难的不是写那几行 Set，而是想清楚：这个 key 的生命周期由谁负责？业务逻辑里有没有重复 Set 导致 TTL 被意外刷新？Redis 配置里 notify 开了没？这些地方一漏，缓存就变成定时炸弹。
