超时问题八成不是Redis慢，而是Lettuce连接池未启用或连接不健康；关键在关闭share-native-connection、配置time-between-eviction-runs为正值、max-wait小于timeout、云环境开启validate-connection和拓扑/DNS刷新，并锁定commons-pool2版本。
直接说结论：超时问题八成不是Redis慢，而是Lettuce连接池“没活过来”或“拿了个死连接”。关键不在timeout调大，而在连接池是否真在用、连接是否真健康。
为什么max-active设了却像没设一样？
Lettuce默认启用shareNativeConnection=true，即多个线程复用同一个物理连接。这时候max-active根本不起作用——池子再大，大家挤一条路。
- 必须显式关闭共享：
spring.redis.lettuce.pool.share-native-connection=false - 否则
max-active、min-idle等参数全部被忽略 - 验证方式：看
LettuceConnectionFactory初始化日志里是否有shareNativeConnection=false
time-between-eviction-runs不配等于没配池
这个参数控制空闲连接驱逐检测周期，值为0或负数（如-1）时，驱逐线程压根不启动，失效连接永远留在池里，直到某次调用突然报RedisCommandTimeoutException。
- 必须设为正值，推荐
30000ms（30秒） - yml中写法必须是
30000ms（带单位），properties中写30000 - 搭配
test-while-idle: true才能真正剔除断连、防火墙踢掉的“僵尸连接”
max-wait和timeout谁该更大？
很多人把max-wait设成-1（无限等待），以为能防超时，结果反而让线程卡死在取连接阶段，拖垮整个服务。
-
max-wait必须小于timeout：比如timeout: 5000ms，则max-wait: 2000ms更安全 - 理由：如果取连接都要等3秒，那留给命令执行的时间只剩2秒，极易触发超时
- 生产建议：
max-wait设为500~1000ms，配合足够min-idle（如5）避免冷启动排队
K8s/云环境必须开validate-connection和拓扑刷新
容器网络里，SLB、NAT网关、Kube-proxy都会主动断开空闲TCP连接（常见300~900秒），而Lettuce默认不校验连接有效性，也不自动感知节点IP变更。
- 加配置：
spring.redis.lettuce.pool.validate-connection=true - 集群模式下必须启用拓扑刷新：
spring.redis.lettuce.cluster.refresh.period=60000ms - 若用单机但走Service域名（如
redis-svc.default.svc.cluster.local），也要开DNS刷新：spring.redis.lettuce.shutdown-timeout=100ms+ 自定义GenericObjectPoolConfig里设setTestOnCreate(true)
最易被忽略的一点：所有这些配置生效的前提，是commons-pool2版本必须显式锁定（如2.11.1）。Spring Boot 2.3+自动引入的某些低版本存在连接泄漏缺陷，不声明就等于埋雷。
