RedisCommandTimeoutException根源在于Lettuce连接池配置缺陷：共享连接未关闭、空闲驱逐未启用、max-wait≥timeout导致取连接即超时；需显式设share-native-connection=false、time-between-eviction-runs>0且test-while-idle=true，并闭环验证Redis服务状态、网络、安全组、URL完整性及commons-pool2依赖。
Spring Boot集成Redis时，连接池异常不是“加个try-catch就能完事”的问题——它背后往往暴露的是连接池没真正启用、连接已失效却还在复用、或销毁逻辑缺失导致资源泄漏。必须从配置源头堵住漏洞，而不是等报错再补。
为什么RedisCommandTimeoutException总在高峰期爆发
这个异常表面是命令超时，实际多由连接池“假活跃”引发：Lettuce默认开启share-native-connection=true，多个线程共用一个物理连接，此时max-active形同虚设；同时time-between-eviction-runs若为0或负值，空闲连接驱逐线程根本不启动，“僵尸连接”长期滞留池中，一到并发高峰就集体失联。
- 必须显式关闭共享：
spring.redis.lettuce.pool.share-native-connection=false -
time-between-eviction-runs必须设为正值（如30000ms），且搭配test-while-idle: true才有效 -
max-wait必须严格小于timeout（例如timeout: 5000ms→max-wait: 2000ms），否则取连接阶段就耗尽超时预算
io.lettuce.core.RedisConnectionException的5个真实检查点
这类连接异常90%不是代码问题，而是环境或配置断层。别急着改Java，先确认这五件事是否都闭环：
- Redis服务本身是否运行：
systemctl status redis，并确认端口6379处于LISTEN状态（netstat -tulnp | grep 6379） -
protected-mode no和bind 0.0.0.0是否同时生效（Docker/K8s环境下尤其注意bind与宿主机网络模式冲突） - 防火墙/安全组是否放行
6379（阿里云需单独配置安全组，CentOS用firewall-cmd --add-port=6379/tcp） -
spring.redis.url是否完整（含密码、数据库号），缺失会导致RedisAutoConfiguration未加载，整个连接池链路失效 - 是否引入了
commons-pool2依赖（spring-boot-starter-data-redis不自动带它，缺则连接池根本不会初始化）
@PreDestroy在RedisConnectionFactory上为何总不触发
这不是注解失效，而是Spring容器压根没把它当Bean管理。常见于手动new LettuceConnectionFactory()、或配置类中返回实例但没加@Bean注解。LettuceConnectionFactory本身实现了DisposableBean，但销毁方法destroy()只会在Bean被容器托管且上下文关闭时调用。
- 正确写法：用
@Bean(destroyMethod = "destroy")显式声明，确保销毁回调注册进容器生命周期 - 验证方式：启动日志里搜
LettuceConnectionFactory，看到destroyMethod被识别才算成功 - 额外保障：配合
LettuceClientConfiguration.shutdownTimeout设为10000ms，避免Netty线程未退出拖慢停机
连接池异常最麻烦的地方不在报错那一刻，而在它悄悄积累——CLOSE_WAIT堆积、maxclients触顶、甚至Redis服务器拒绝新连接。所有参数调优都得配合真实压测验证，尤其是min-idle设太低会导致冷启动时大量连接重建，反而加剧超时。
