Spring Boot 启动时 Redis 连接慢导致 readiness probe 失败，因 Lettuce 连接池初始化阻塞上下文刷新；应设 spring.redis.timeout=1000、pool.max-wait=500、shutdown-timeout=100，并对 LettuceConnectionFactory @Bean 加 @Lazy，K8s 探针配 initialDelaySeconds≥30。
Spring Boot 启动时 Redis 连接慢，直接导致 /actuator/health/readiness 返回 500 或超时，Kubernetes 就绪探针连续失败后把 Pod 从 Service 的 Endpoints 中踢掉——这不是应用“没写好”，而是连接初始化卡在容器启动早期，探针却已开始轮询。
为什么 readiness probe 在启动完成前就失败了
Readiness 探针默认从容器启动后立即开始探测（initialDelaySeconds 默认为 0），而 Spring Boot 的 Redis 连接池初始化发生在 ApplicationContext.refresh() 阶段早期。只要 classpath 里有 spring-boot-starter-data-redis，Lettuce 就会尝试预热连接池；若 Redis 不可达，它会静默等待 spring.redis.timeout（默认 2 秒）才抛异常。这期间整个 Spring 上下文卡住，Actuator 健康端点无法响应，探针拿到 HTTP 500 或连接拒绝，连续失败三次即标记 NotReady。
- 日志里最早出现的耗时堆栈通常落在
LettuceConnectionFactory.afterPropertiesSet()或DefaultClientResources.create() -
kubectl describe pod的 Events 区域会出现类似Readiness probe failed: HTTP probe failed with statuscode: 500 - 哪怕你没用 Redis，只要引入了 starter，这个初始化逻辑就存在
application.yml 中必须改的三个 timeout 参数
不是加 @Lazy 就万事大吉，也不是靠调大超时来“等它好”。关键是要让失败更快暴露，避免阻塞主线程：
-
spring.redis.timeout: 1000—— 覆盖 Lettuce 默认 2 秒连接超时，设为 1 秒 -
spring.redis.lettuce.pool.max-wait: 500—— 获取连接排队超时设为 500ms，防池满死等 -
spring.redis.lettuce.shutdown-timeout: 100—— 关闭连接等待缩到 100ms，避免本地反复启停残留连接干扰
注意：spring.redis.timeout 控制的是 TCP 连接建立耗时，不是命令执行超时；光调这个不够，必须配合下一条的懒加载。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
@Lazy 必须加在 Bean 定义处，不是@Service上
只给某个 @Service 类加 @Lazy 没用，因为触发连接的是 LettuceConnectionFactory 初始化本身。真正要延迟的是连接工厂的创建时机：
- 在配置类中，给
@Bean方法加@Lazy：<code>@Bean @Lazy public LettuceConnectionFactory redisConnectionFactory() { ... }</code> - 如果用了多个 RedisTemplate，每个对应的
@Bean方法都得加，否则任一未懒加载的 Bean 都会触发连接 - Spring Boot 3.2+ 可配合
spring.redis.client-name: lazy-init-client显式标识该连接用于懒初始化场景
K8s 探针必须配 initialDelaySeconds
即使修复了 Redis 初始化，Spring Boot 启动仍需加载配置、初始化 JPA、扫描组件等。不给足缓冲时间，readiness probe 依然抢在 Actuator 端点就绪前开查：
- 最低安全值建议设为
initialDelaySeconds: 30（开发环境可设 15，生产建议 30+） - 同时设
failureThreshold: 5和periodSeconds: 10，避免偶发网络抖动误判 - 不要依赖 liveness probe 来“兜底”——它重启容器只会让问题循环发生
最易被忽略的一点：Redis 连接慢只是表象，背后往往是网络策略（如 K8s Service 的 endpoint 不稳定）、中间件超时（如 NLB 350 秒断连）或拓扑刷新滞后（Redis Cluster 节点 IP 变更后客户端未感知）。单靠调参只能止血，得结合 io.lettuce.core.tracing=stdout 日志和 kubectl logs -p 看前一个容器的失败原因，才能定位根因。
