Spring Boot 3.x启动时Redis连接失败导致应用卡死，根本原因是LettuceConnectionFactory在上下文刷新阶段强制建连，而非配置或超时问题；解决关键在于延迟连接（@Lazy）或禁用初始化校验（如关闭RedisHealthIndicator）。
Spring Boot应用启动时Redis无法连接，根本不是“连不上缓存”的问题，而是应用直接起不来——因为默认行为会强制在上下文刷新阶段建立连接。解决的关键不是让连接更快，而是让连接不阻塞启动。
为什么Spring Boot 3.x+启动时会因Redis失败而卡死
Spring Boot 2.6起，默认开启严格健康检查，LettuceConnectionFactory在refresh()阶段就会调用getConnection()。一旦Redis不可达（宕机、网络不通、密码错误），立刻抛出RedisConnectionFailureException，触发ApplicationContext初始化中断。
这不是配置漏了超时，也不是代码写错了，是Spring把Redis当成了“必需基础设施”而非可选组件。
- 单纯加大
spring.redis.timeout没用——它只控制命令执行超时，不控制连接初始化时机 -
connect-timeout和time-out设得再小，只要没配合懒加载，仍会在refresh阶段触发连接 - 若用了
RedisHealthIndicator（如启用了Actuator），还会在/actuator/health端点二次校验，进一步拖垮启动
让启动绕过Redis连接检测的两种可靠方式
核心思路只有两个：延迟连接时机，或跳过初始化校验。别信“重试三次就OK”的方案，那只是掩盖问题。
- 在配置类中对
@Bean方法加@Lazy：必须作用于RedisConnectionFactory或RedisTemplate定义处，而不是@Service层 - 禁用自动连接验证（Spring Boot 3.2+）：
spring.redis.lettuce.shutdown-timeout=100ms+spring.redis.lettuce.time-out=100ms，并确保未启用RedisHealthIndicator - 开发/测试环境更直接的做法：在
application.yml里加management.endpoint.health.show-details=never，并显式排除redis健康指示器
启动后运行时Redis宕机，怎么降级才可控
@Cacheable本身无降级能力——Redis连接失败时，RedisCacheManager直接抛异常，整个方法调用就崩了。你不能靠注解兜底，必须显式控制流程。
- 弃用
@Cacheable做主缓存逻辑，改用RedisTemplate手动操作，并在外层try-catch捕获DataAccessException及其子类（如RedisConnectionFailureException） - 本地缓存推荐
Caffeine而非ConcurrentHashMap：前者支持过期、淘汰、统计监控，后者只是个Map，没生命周期管理能力 - 用
AtomicBoolean redisAvailable做可用性标记，避免每次请求都重试连接；但注意它不解决集群节点局部故障，需配合更细粒度探测
容易被忽略的兼容性细节
Spring Boot 3.x底层用的是Lettuce 6.x，它对DNS解析、RESP协议版本、SSL握手更敏感，很多“启动失败”其实和Redis本身无关。
- Linux容器内用
localhost可能解析失败，建议显式配127.0.0.1 - Redis 7+默认启用RESP3，旧版Lettuce可能握手失败，需在
LettuceClientConfiguration中显式指定ProtocolVersion.RESP2 - Docker环境下，宿主机
127.0.0.1指向容器内部，应改用宿主机真实IP或Docker网络别名（如host.docker.internal）
真正难的不是让服务“能跑起来”，而是让降级路径在压测和故障演练中可验证、不污染主流程、不掩盖真实瓶颈——比如本地缓存没设最大容量，Redis恢复后数据长期不更新，这种“伪降级”比直接报错更危险。
