go-redis连接池需合理配置PoolSize、MinIdleConns、ConnMaxIdleTime等参数：PoolSize按QPS×(RTT+平均耗时)估算并加余量；MinIdleConns≤PoolSize且建议5～10；v8起用ConnMaxIdleTime（如5min）替代已弃用的IdleTimeout，并配IdleCheckFrequency；PoolTimeout须≥Read/WriteTimeout，且必须设ConnMaxLifetime防幽灵连接。
go-redis 的连接池不是“开了就自动最优”的，PoolSize、MinIdleConns、IdleTimeout 这三个参数配错，轻则连接数抖动、超时频发，重则 GC 压力飙升、服务雪崩。
PoolSize 设多少才不踩坑
默认值是 10 * runtime.NumCPU()，在本地开发或低并发场景下可能偏大，但线上高并发服务又常嫌不够。关键不是看 CPU 核数，而是看你的 Redis 实例吞吐能力和单请求平均耗时。
- 若单次 Redis 操作平均耗时 2ms，QPS 达到 5000，则理论最小并发连接需 ≈ 5000 × 0.002 = 10，再加 20% 余量 →
PoolSize: 12起步够用 - 若 Redis 部署在远端（如跨可用区），网络 RTT 高，
PoolSize要按QPS × (RTT + avg_cmd_time)重新估算，否则会大量卡在PoolTimeout - 设得过大（比如盲目设成 1000）会导致空闲连接堆积，触发频繁的
IdleCheckFrequency扫描，增加 goroutine 和 timer 开销
MinIdleConns 不是“越多越好”
MinIdleConns 是连接池启动后就预热并长期维持的空闲连接数。它解决的是“突发流量来临时来不及建连”的问题，但前提是这些连接真能被复用上。
- 必须 ≤
PoolSize，否则无效；设为 0 表示不预热，首次请求才会建第一个连接 - 设为 5～10 对中等业务较稳妥；若你用的是 Kubernetes 环境且 Pod 启动后立刻有压测流量，建议设
MinIdleConns: 8配合PoolSize: 20 - 注意：
MinIdleConns只影响“空闲连接下限”，不阻止连接被回收 —— 回收由ConnMaxIdleTime或IdleTimeout控制（v8 版推荐用前者）
IdleTimeout 和 ConnMaxIdleTime 到底该用哪个
v8 版本起，IdleTimeout 已被标记为 deprecated，应改用 ConnMaxIdleTime。两者语义不同，混用会引发连接提前关闭或长期滞留。
立即学习“go语言免费学习笔记（深入）”；
-
IdleTimeout（旧）：控制连接池内部空闲连接的存活上限，单位秒；设太短（如30 * time.Second）会导致连接刚空闲就销毁，重建开销上升 -
ConnMaxIdleTime（新）：真正控制 TCP 连接本身的最大空闲时间，单位是time.Duration；建议设为5 * time.Minute，既防连接老化，又避免长连接占用过多 fd - 配套必须设
IdleCheckFrequency: time.Minute，否则空闲连接不会被及时清理；不设或设太大（如 30 分钟），可能导致失效连接堆积
PoolTimeout 和 Read/WriteTimeout 的协同逻辑
这三个 timeout 不是孤立的：它们共同决定客户端在什么阶段放弃等待、报什么错。顺序是 DialTimeout → PoolTimeout → ReadTimeout/WriteTimeout。
-
PoolTimeout默认是ReadTimeout + 1s，意思是“如果等不到空闲连接，最多忍PoolTimeout后直接报redis: connection pool timeout” -
ReadTimeout和WriteTimeout是 socket 级超时，只对已拿到的连接生效；设为-1会禁用 deadline，导致 goroutine 永久阻塞（别这么干） - 常见错误：把
PoolTimeout设成 100ms，但ReadTimeout设成 5s —— 结果大部分请求根本等不到连接就失败了，根本走不到读阶段
最易被忽略的一点：ConnMaxLifetime 必须设，哪怕只是 30 * time.Minute。Redis 连接长期存活可能因中间网络设备（如 SLB、NAT 网关）静默断连，而客户端无感知；靠 ConnMaxLifetime 强制轮转才能暴露并重建这类“幽灵连接”。
