PoolTimeout必须小于ReadTimeout，建议设为ReadTimeout×0.7；若SLA为200ms、ReadTimeout为150ms，则PoolTimeout不宜超100ms，设-1等于放弃熔断，线上禁止。
PoolTimeout 设置必须小于 ReadTimeout
很多团队把 PoolTimeout 设成和 ReadTimeout 一样大，甚至更大，结果一到高并发就卡住。这是因为当连接池耗尽时，客户端先等 PoolTimeout，再用拿到的连接去读数据——如果 PoolTimeout 已经占满总超时预算，ReadTimeout 就没时间了，直接触发上层超时。go-redis 默认 PoolTimeout 是 ReadTimeout + 1s，看似合理，但实际中建议显式设为 ReadTimeout × 0.7 左右，给网络抖动留余量。
常见错误现象：redis: connection pool timeout 报错频发，但 connected_clients 在 Redis 端并不高。
-
PoolTimeout应该是「等待连接」的上限，不是「整个操作」的上限 - 若业务接口 SLA 是 200ms，
ReadTimeout设 150ms，则PoolTimeout不建议超过 100ms - 设为 -1（无限等待）等于放弃熔断能力，线上禁止
maxIdle 和 minIdle 不要盲目设高
ioredis、Lettuce 这类基于 Netty 的客户端默认不暴露传统意义上的 maxIdle/minIdle，但 Jedis 和部分老版本封装库仍依赖这些参数。设太高会导致空闲连接长期不释放，占用服务端 fd；设太低则频繁创建销毁连接，引发 TIME_WAIT 暴增或 accept queue overflow。
使用场景：QPS 300 的服务，平均响应 10ms，连接复用率高，不需要维持大量空闲连接。
- 推荐公式：
minIdle ≈ QPS × avgRT × 0.3（例如 300 × 0.01 × 0.3 ≈ 1） -
maxIdle建议不超过minIdle × 3，避免连接池“虚胖” - Spring Boot 自动配置里
spring.redis.jedis.pool.max-idle默认是 8，对中小流量够用，但上线前务必压测验证
连接泄漏时 PoolTimeout 会掩盖真实问题
一旦发生连接泄漏（比如 client.Get().Val() 后忘了 Close() 或没用 defer），连接池里的活跃连接数会持续上涨，最终所有连接都被占满。这时你看到的报错全是 redis: connection pool timeout，但根源是泄漏，不是池子小。
容易踩的坑：在 defer 里调用 conn.Close() 对 go-redis 无效——它用的是连接池，Close() 只是归还，不是销毁；真正泄漏是没执行归还逻辑（比如 panic 跳出了 defer 范围，或用了错误的 client 实例）。
- 开启 go-redis 的
PoolStats()定期打点，监控HitCount和Misses比值突降 - 检查日志里是否频繁出现
connection pool is full且connected_clients持续缓慢上升 - 用
netstat -anp | grep :6379 | wc -l在客户端机器上核对 ESTABLISHED 数量，和应用内PoolStats().TotalConns是否一致
DialTimeout 和 ReadTimeout 必须分开调，不能只调一个
有人遇到 “偶尔连不上”，就把 DialTimeout 从 5s 改成 10s，结果读超时还是爆。这是混淆了两个阶段：建立 TCP 连接是一回事，命令发过去之后等响应是另一回事。网络延迟高、Redis 主机负载高、慢查询堆积，都会影响 ReadTimeout，跟连接建立无关。
性能影响：把 ReadTimeout 设太短（如 100ms），会导致正常的大 key GET 或 HGETALL 被粗暴中断；设太长（如 10s），会让单个慢请求拖垮整个线程/协程。
- 写操作（
SET,INCR）一般WriteTimeout300–500ms 足够 - 读操作按业务容忍度分档：
GET类建议 800ms–1.2s，SCAN或聚合类命令单独用 context 控制 -
DialTimeout在内网环境可设为 1–2s；跨可用区或带 TLS 时建议 3–5s
PoolTimeout 和业务接口的超时预算对齐，也没有用 PoolStats() 验证连接是否真的被归还。 
