缓存预热不能用@PostConstruct是因为其执行时Redis连接等外部资源可能未就绪，易抛RedisConnectionFailureException；而CommandLineRunner在所有Bean及Redis资源就绪后执行，更安全可靠。
为什么缓存预热不能靠 @PostConstruct
因为 @PostConstruct 执行时，Spring 容器可能还没完成 Redis 连接初始化（比如 LettuceConnectionFactory 尚未就绪），容易抛出 RedisConnectionFailureException 或空指针。而 CommandLineRunner 是 Spring Boot 生命周期中明确保证「所有 Bean 加载完毕、外部资源（如 Redis）已可用」后的回调点。
如何正确实现 CommandLineRunner 做缓存预热
定义一个 @Component 类，实现 CommandLineRunner 接口，注入 StringRedisTemplate 或 RedisTemplate 即可安全操作 Redis：
@Component
public class RedisCacheWarmer implements CommandLineRunner {
private final StringRedisTemplate redisTemplate;
public RedisCacheWarmer(StringRedisTemplate redisTemplate) {
this.redisTemplate = redisTemplate;
}
@Override
public void run(String... args) throws Exception {
// 示例：预热用户基础信息（假设 key 格式为 "user:123"）
List<Long> userIds = Arrays.asList(1L, 2L, 3L);
for (Long id : userIds) {
String key = "user:" + id;
if (!redisTemplate.hasKey(key)) {
String value = loadUserFromDb(id); // 你自己查 DB 的方法
redisTemplate.opsForValue().set(key, value, 1, TimeUnit.HOURS);
}
}
}
private String loadUserFromDb(Long id) {
// 模拟从数据库加载
return "{\"id\":" + id + ",\"name\":\"user-" + id + "\"}";
}
}
- 务必检查
redisTemplate.hasKey(key)，避免覆盖已有缓存或重复加载 - 预热逻辑要轻量；如果数据量大，考虑分页、异步或加限流，否则会拖慢启动时间
- 不要在
run()中 throw 未捕获异常，否则 Spring Boot 启动失败
预热失败时怎么排查
常见现象是应用启动成功但缓存没写入，或者日志里出现 Cannot get Jedis connection 类错误。优先确认以下几点：
-
spring.redis.host和spring.redis.port配置是否正确，且 Redis 实例可连通（用redis-cli -h xxx -p xxx ping验证） - 是否启用了 Redis 密码但没配
spring.redis.password - 是否配置了
spring.redis.timeout过短，导致连接超时被静默忽略 - 检查日志中是否有
RedisCacheWarmer : Running...—— 如果没有，说明该 Bean 没被扫描到（确认类在主启动类包路径下或显式@ComponentScan）
要不要加 @Order 控制执行顺序
一般不需要。除非你的预热逻辑依赖另一个 CommandLineRunner（比如先初始化配置中心再读配置去预热），才需要加 @Order 注解。但更推荐把强依赖收敛到同一个 Runner 内部处理，避免隐式耦合。
缓存预热本身是个“尽力而为”的动作；真正关键的是首次访问时的降级兜底（比如用 @Cacheable + sync = true 防击穿），而不是把它变成启动强依赖。
