Redis连接数爆满的元凶是业务程序而非宝塔面板，主因包括Jedis连接池配置错误（如maxTotal=-1）、未调用jedis.close()导致连接泄漏、空闲连接未清理等。
Redis连接数爆满时，宝塔面板本身不是元凶
宝塔面板的 Redis 管理模块（如“Redis”插件页、状态监控）只会在你主动点击或刷新时建立**短暂、单次**的连接，用完即断。它不会持续占用连接，更不会导致 connected_clients 从几百秒升到上万。真正的问题一定出在你部署在宝塔上的业务程序里——尤其是用了 Jedis、Lettuce 或 redis-py 的那些服务。
Jedis 连接池配置错误：maxTotal=-1 是定时炸弹
很多开发者复制粘贴网上示例，直接写 config.setMaxTotal(-1)，以为“无限连接=高可用”，实际是把连接池变成了连接黑洞。一旦并发请求激增，Jedis 就会无节制创建新物理连接，直到打穿 Redis 的 maxclients 或系统 ulimit -n 限制。
-
maxTotal=-1：禁止使用，必须设为明确正整数（如200） -
maxIdle > maxTotal：无效配置，会被忽略，但说明你没理解参数含义 -
testOnBorrow=false+testWhileIdle=false：空闲连接可能已断开却未被清理，借出时直接报错，触发重试逻辑，进一步加剧连接创建 - 未设置
timeBetweenEvictionRunsMillis和minEvictableIdleTimeMillis：空闲连接永久滞留，连接数只增不减
Java 程序里没调 jedis.close() 就等于拔电源
这是最常见也最隐蔽的泄漏点。Jedis 不是自动回收资源的“智能对象”，jedis.close() 调用本质是把连接归还给池子；漏掉这句，连接就永远卡在“已借出”状态，池子以为它还在干活，永远不会复用或销毁它。
- 错误模式：
jedis.get("key")后直接 return，没包try-finally或try-with-resources - 异常分支陷阱：
catch块里没 close，finally里又忘了判空，jedis为 null 时调用close()报 NPE，反而掩盖了原始业务异常 - Spring Boot 用户注意：
@Autowired RedisTemplate是安全的，但如果你手动 newJedis或调jedisPool.getResource()，就回到了裸写风险区
用 redis-cli client list 快速定位泄漏源头
别猜，直接看谁在连。在宝塔终端或 SSH 里执行这条命令，能立刻暴露真实客户端行为：
redis-cli client list | grep -E 'addr|idle|cmd' | head -20
重点关注三列：
-
addr：来源 IP 和端口 —— 对应你宝塔里哪个站点/进程？ -
idle：空闲秒数 —— 如果大量连接idle超过 300 秒且cmd为空，基本确认是泄漏未释放 -
cmd：最后执行命令 —— 全是get或set但idle很高，说明业务逻辑卡住或提前退出没 cleanup
如果看到同一 IP 后缀端口持续递增（如 192.168.1.100:54321、192.168.1.100:54322），说明程序每次请求都在新建连接而非复用，十有八九是连接池根本没生效，或者压根没配连接池，直接 new Jedis()。
