Lettuce连接“悄无声息地断”是因为默认不启用PING和TCP keepalive，空闲连接被中间设备静默回收；需配置time-between-eviction-runs、min-idle、shutdown-timeout，并开启adaptive拓扑刷新与Socket层keepAlive。
为什么Lettuce连接会“悄无声息地断”？
不是Redis挂了，也不是网络不通——而是连接在你没操作时被中间设备（防火墙、SLB、NAT、Windows TCP栈）静默回收了。Lettuce默认不发PING、不启TCP keepalive，空闲连接就像一张过期车票，表面有效，实则失效。下次取连接执行redisTemplate.opsForValue().get("key")时，才暴露问题：RedisCommandTimeoutException或Connection reset by peer。
必须配的三个核心参数
光调spring.redis.timeout没用，得从连接生命周期源头干预：
-
spring.redis.lettuce.pool.time-between-eviction-runs=30s：启用空闲连接驱逐检测周期，否则连接池永远不知道连接已死 -
spring.redis.lettuce.pool.min-idle=8：保持常驻连接数，避免冷启动后首次请求才建连（此时容易撞上刚被掐断的旧连接） -
spring.redis.lettuce.shutdown-timeout=500ms：防止应用停机时Lettuce强行等未完成命令，导致Spring上下文销毁卡住
心跳保活不能只靠“pingBeforeActivateConnection”
设pingBeforeActivateConnection(true)看似能解决，但有硬伤：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 若Redis配置了密码，而
RedisURI里没带auth字段，PING会失败并抛AuthenticationException - 它只在连接从池中取出时触发，无法覆盖连接空闲期间的断连风险
- 它不等价于TCP层keepalive，对云厂商SLB的60秒空闲超时无效
真正兜底的做法是：在LettuceClientConfiguration里显式启用ClientOptions.builder().socketOptions(SocketOptions.builder().keepAlive(true))，让操作系统接管保活。
集群拓扑刷新不是可选项，是必选项
单节点Redis断连还能靠重试扛过去，Redis集群下不刷新拓扑就是慢性死亡——节点宕机后继续往失效IP发命令，永远收不到响应。
-
spring.redis.lettuce.cluster.refresh.adaptive=true：必须开，它监听MOVED/ASK重定向和连接断开事件，秒级响应变更 -
spring.redis.lettuce.cluster.refresh.period=60s：补漏用，防自适应机制漏掉的边缘场景（比如节点静默下线没触发重定向） - 注意：
refresh.period设太小（如5s）会导致每分钟发起数十次CLUSTER NODES请求，压垮Redis小集群
没有自适应刷新，哪怕配置再全，集群一动你就得手动重启服务——这不是高可用，是高维护。
