min-idle应设为max-active的20%～50%作为常驻水位，而非默认0；需同步配置time-between-eviction-runs-millis、min-evictable-idle-time-millis和max-wait才能生效，并依据redis.lettuce.pool.idle监控动态调优。
没有放之四海而皆准的“黄金法则”，只有匹配你业务流量模型和硬件资源的参数组合。 盲目套用网上流传的 max-active: (cpu * 2) + 2 或 min-idle: 10，反而容易引发连接超时或资源浪费。
min-idle 设为 0 是生产环境最常见的性能雷区
很多项目直接用默认值 min-idle: 0，压测时突然出现大量 RedisCommandTimeoutException，日志里反复打印 Creating new connection because pool is empty。这不是 Redis 慢，是每次请求都得走一遍 TCP 握手 + AUTH 认证，开销远大于复用连接。
- 适用场景仅限极低频任务（如每小时一次的定时同步），日常 Web 接口绝对不能设为 0
- 它不是“保底数量”，而是“常驻水位”——确保突发流量来临时，有现成连接可立即响应
- 推荐起点：若
max-active: 20，先设min-idle: 6（即 30%），再结合监控指标redis.lettuce.pool.idle调整：长期 ≈ 0 → 加；长期 ≈min-idle→ 减
max-active 和 CPU 核心数的关系不是算术题
max-active 决定的是并发连接上限，但真实活跃连接数取决于你的操作耗时和线程调度。设太高，Redis 服务端连接数暴涨、内存压力上升；设太低，线程卡在 borrowObject 上等待，表现为毛刺延迟。
- 高并发短操作（如商品详情缓存读）：可设为
(cpu 核心数 × 2) + 2，例如 8 核 →max-active: 18 - 含批量写入或长耗时命令（如
pipeline或 Lua 脚本）：必须降低，避免单个连接阻塞太久拖垮整个池 - 必须配合
max-wait: 2000（单位毫秒）显式设置，否则无限等待会掩盖配置问题，超时后日志能明确提示 “Unable to acquire connection”
三个参数不配齐，min-idle 就是摆设
min-idle 不是独立生效的。它依赖后台驱逐机制维持空闲连接，否则刚预热好的连接几秒后就被回收，等于白设。
-
time-between-eviction-runs-millis必须启用（如60000），否则空闲连接永不扫描 -
min-evictable-idle-time-millis必须大于预期空闲驻留时间（如设300000即 5 分钟），否则连接存活不到 30 秒就被踢出 -
max-wait必须设为正数（如2000），避免无限阻塞导致故障不可见
真正难的不是填几个数字，而是把 min-idle、max-active、max-wait、time-between-eviction-runs-millis 和 min-evictable-idle-time-millis 这五者看作一个联动系统——改其中一个，其他四个几乎必然要跟着动。线上调参，永远从监控数据出发，而不是从“别人家的配置”出发。
