min-idle设为0会引发rediscommandtimeoutexception，因每次请求都新建连接导致qps突增时线程卡在borrowobject，日志频繁出现“creating new connection because pool is empty”，最终超时或响应毛刺；仅适用于极低频后台任务。
min-idle设为0会引发RedisCommandTimeoutException
很多项目直接用默认值 min-idle: 0，看起来省事，但实际会导致每次请求都新建连接。Lettuce 必须完成 TCP 握手 + AUTH 认证，QPS 突增时大量线程卡在 borrowObject 上，日志里频繁出现 Creating new connection because pool is empty，最终抛出 RedisCommandTimeoutException 或响应毛刺（比如压测中 50% 请求延迟 >200ms）。
- 仅适用于极低频后台任务（如每小时一次的定时同步）
- 不是“越小越省资源”，而是彻底放弃池化意义
- 一旦业务有突发流量，这个配置就是第一道崩塌点
max-active和min-idle要按业务类型配比例
min-idle 不是孤立参数，它本质是 max-active 的保底水位。设太高浪费连接资源（Redis 端连接数、内存、文件描述符都会涨），设太低又扛不住瞬时并发。
- 读多写少、响应快的接口（如商品详情页）：
min-idle取max-active的 20%～30% - 混合型业务（含批量写入或事务）：
min-idle取max-active的 30%～50% - 若
max-active: 20，min-idle: 6是比默认0或随意填10更稳妥的起点 - 必须结合监控看
redis.lettuce.pool.idle指标：长期 ≈min-idle说明设高了；长期 ≈0说明设低了
启用min-idle必须同步调这三个配套参数
min-idle 生效的前提是整个池子能稳定维持“预热态”。如果其他参数没对齐，它就只是个摆设。
-
time-between-eviction-runs-millis必须启用（如设为60000），否则空闲连接不会被定期扫描，min-idle就无法触发预创建 -
min-evictable-idle-time-millis要明显大于连接预期驻留时间（例如设成30000会导致刚建好的空闲连接 30 秒就被踢出） -
max-wait建议显式设为正数（如2000），避免无限等待掩盖问题；超时后日志会出现明确的Unable to acquire Jedis connection类错误，便于定位
Lettuce 默认不池化，别盲目加commons-pool2
Spring Boot 2.x/3.x 默认用 Lettuce，它基于 Netty，单连接就能撑 3K～5K QPS。官方明确不推荐开启池化——除非你真有高并发且需严格隔离连接的场景（比如不同业务线共用一个 Redis 实例，怕互相干扰）。
- 如果只是普通缓存读写，保持默认（不引入
commons-pool2，不配lettuce.pool.enabled: true）反而更稳 - 如果确实需要池化，必须手动引入
commons-pool2依赖，并显式开启enabled: true - Jedis 则相反：必须池化，否则每次操作都新建连接，性能灾难
redis.lettuce.pool.idle 和 redis.lettuce.pool.active 这两个指标在压测中的波动节奏——它们才是连接池是否“呼吸正常”的真实心跳。
