maxIdle过小导致连接频繁创建销毁，加剧CPU、GC及文件描述符压力；过大则浪费资源并干扰监控；应与maxActive按0.5~0.7比例协同设置，且需注意不同客户端对maxIdle语义的差异。
maxIdle 过小：连接频繁创建销毁，CPU 和 fd 持续承压
当 maxIdle 设置过低（比如设为 2 或 0），连接池无法保留足够空闲连接，业务突发流量来临时，池中无可用连接，只能新建连接；请求结束后又因空闲数超限被立即销毁。这导致：
• 每次新建连接触发 TCP 三次握手 + TLS 握手（如启用 SSL），增加平均延迟
• 频繁分配/释放 socket，加剧 GC 压力（Java）或内存碎片（Go/Python）
• 文件描述符（fd）反复开闭，容易触达系统 ulimit -n 上限，报 Too many open files
• Redis 侧看到大量短连接，TIME_WAIT 状态堆积，影响服务端连接复用效率
maxIdle 过大：空闲连接长期滞留，浪费资源且干扰监控
maxIdle 显著高于实际并发需求（例如设为 200，但平均活跃连接仅 15），会带来隐蔽风险：
• 空闲连接持续占用 fd 和内存，尤其在多实例部署时放大资源消耗
• 连接长时间未使用，可能被中间设备（NAT、LB）静默断连，但客户端未感知，后续首次使用时才报 Connection reset 或 Broken pipe
• 监控指标（如 connected_clients）虚高，掩盖真实连接压力，误导容量判断
• 若配合 minIdle > 0，还会强制保活这些“僵尸连接”，进一步加重负担
maxIdle 与 maxActive 不匹配：池行为失控的典型信号
maxIdle 不应孤立设置，它和 maxActive 的比例直接决定池的弹性表现：
• 常见合理范围是 maxIdle = 0.5 × maxActive 到 0.7 × maxActive（例如 maxActive=50 → maxIdle=25~35）
• 若 maxIdle == maxActive，等价于禁用连接回收，空闲连接永不释放，等于放弃弹性调节能力
• 若 maxIdle > maxActive，多数客户端库（如 Jedis、Lettuce）会静默忽略，但配置逻辑已失焦，易引发团队理解偏差
• 在 Lettuce 中，该参数实际作用于 GenericObjectPoolConfig，若与 max-active 冲突，优先以 max-active 为准，但日志中会出现 “maxIdle ignored” 类提示
不同客户端对 maxIdle 的语义差异容易被忽略
同名参数在不同 Redis 客户端中含义并不完全一致：
• Jedis：maxIdle 是**最大空闲数**，受 minEvictableIdleTimeMillis 控制回收时机
• Lettuce：maxIdle 已被弃用，对应功能由 max-idle（Spring Boot 配置项）或 GenericObjectPoolConfig.setMaxIdle() 提供，但底层依赖 Apache Commons Pool，行为更复杂
• redis-py：max_connections 是总上限，**没有直接的 maxIdle 参数**，空闲管理由连接池自动完成，需靠 retry_on_timeout 和 health_check_interval 间接调控
• 实际排查时，不能只看参数名，必须核对所用客户端版本文档，否则调优动作可能完全无效
