缓存预热应在系统启动后、大促前2小时、配置批量更新后等流量高峰前完成，而非上线后补救；常见错误是用@PostConstruct同步阻塞启动，正确做法是启动后异步执行或手动触发，并通过健康检查确认DB与Redis可用后再执行。
缓存预热该在什么时机触发
预热不是上线后才想起来的事，而是必须卡在流量高峰前完成。系统刚启动、大促前 2 小时、配置中心批量更新后，都是典型触发点。如果等到用户请求进来再加载，就不是预热，是“现烤”，已经算雪崩前奏了。
常见错误是把预热写在 @PostConstruct 方法里，结果服务启动慢、依赖超时、甚至因数据库连接未就绪而失败。更稳妥的做法是：启动后异步执行，或通过独立管理接口手动触发，配合健康检查确认 DB 和 Redis 可用后再跑。
- 全量预热适合数据量小（
- 按需预热更适合商品、用户画像等大数据集，靠访问日志或监控识别 top 100 热 key，只加载这部分
- 定时预热建议放在凌晨低峰期，避免和业务高峰期重叠
预热代码里最容易漏掉的三个细节
预热逻辑看着简单，但生产环境出问题基本都栽在这几个点上：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
redisTemplate.opsForValue().set(key, value, timeout, TimeUnit.SECONDS)的timeout必须设——不设就是永不过期，脏数据会一直滞留；设得太短又失去预热意义，建议比业务平均 TTL 多留 20% - 预热过程中遇到单条数据加载失败（如 DB 查询超时），不能直接中断整个流程，要 catch 异常 + 打日志 + 继续下一条，否则预热半途而废
- 千万别在预热循环里反复 new
RedisConnection或开事务，容易打满连接池；复用已有 template，批量操作优先用pipeline
预热后怎么验证是否真正生效
发个 HTTP 请求调完预热接口，不代表数据真进了 Redis。必须验证，否则等于没做。
- 用
redis-cli -h xxx -p 6379 keys "hot_*"检查 key 是否存在（注意线上禁用keys *，改用scan） - 查
ttl hot_user_123确认过期时间符合预期，不是 -1（永不过期）或 0（已过期） - 用
monitor命令抓几秒流量，看是否有大量get请求命中这些 key，而不是穿透到 DB
预热不是一次性动作，它和随机 TTL、互斥锁、降级开关一样，是雪崩防护链条里可测量、可回滚的一环。漏掉验证，就等于埋了个假警报器。
