min-idle设为0很危险，因突发流量时需频繁新建连接，引发tcp握手和auth开销，导致rediscommandtimeoutexception及响应毛刺；仅适用于极低频后台任务。
min-idle 不是“设得越高越好”，它必须和业务并发模型、连接获取频率、以及 max-wait 配合使用；设太高会浪费连接资源，设太低则在突发流量下容易触发阻塞或超时。
为什么 min-idle 设为 0 很危险
很多项目直接沿用默认值 min-idle: 0，看起来省事，但实际会导致：每次新请求来临时，Lettuce 必须新建连接（哪怕只是短暂借用），而连接建立本身有 TCP 握手 + Redis AUTH 开销。在 QPS 突增时，大量线程卡在 borrowObject 上，表现为 RedisCommandTimeoutException 或响应毛刺。
- 现象：压测中 50% 请求延迟 >200ms，
lettuce-core日志频繁出现Creating new connection because pool is empty - 本质：空闲池长期为空，所有连接都是“即借即建”，失去池化意义
- 适用场景：仅限极低频、后台批处理类任务（如每小时跑一次的定时同步）
min-idle 和 max-active 的比例关系
不能孤立调 min-idle。它应作为 max-active 的“保底水位”，确保池中始终有可立即响应的连接。经验上建议：
- 读多写少、响应快的接口（如商品详情）：
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 生效的前提是整个连接池行为协调一致，否则可能被其他参数“抵消”：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
time-between-eviction-runs-millis必须启用（如60000），否则空闲连接不会被定期扫描，min-idle就只是个静态声明 -
min-evictable-idle-time-millis要大于min-idle的预期驻留时间，否则刚预热好的空闲连接马上被回收（例如设成30000会导致连接存活不到 30 秒就被踢出） -
max-wait建议显式设为正数（如2000），避免无限等待掩盖min-idle不足的问题；一旦超时，日志里能清晰看到 “Unable to acquire Jedis connection” 类错误
真实配置片段示例（Lettuce + YAML）
以下不是模板，而是已在线上验证过的轻量级配置（适用于单机 Redis、QPS 300 左右的服务）：
spring:
redis:
host: 127.0.0.1
port: 6379
timeout: 2000
lettuce:
pool:
max-active: 20
max-idle: 15
min-idle: 6
max-wait: 2000
time-between-eviction-runs-millis: 60000
min-evictable-idle-time-millis: 180000
关键点：这里 min-idle: 6 并非拍脑袋，而是基于平均连接复用周期 3 分钟（min-evictable-idle-time-millis: 180000）和每秒约 5 次连接借出频率反推得出；上线后通过 Micrometer 暴露的 pool.idle 和 pool.active 指标确认其稳定在 5～7 区间。
真正容易被忽略的，是 min-idle 的“动态合理性”——它不取决于你希望有多少连接空着，而取决于你的应用在最忙的 10 秒内，平均每秒需要从池子里借出几次连接。算不清这个数，光调参数就是碰运气。
