redigo 的 redis 连接不支持并发调用 do()、send()、flush() 或 receive()；单连接无法安全用于多 goroutine 场景，必须通过连接池获取独立连接，并在使用后及时归还，才能实现真正并发安全的 redis 访问。
redigo 的 redis 连接不支持并发调用 do()、send()、flush() 或 receive()；单连接无法安全用于多 goroutine 场景，必须通过连接池获取独立连接，并在使用后及时归还，才能实现真正并发安全的 redis 访问。
Redigo 的并发模型有明确限制：单个 redis.Conn 实例仅允许一个活跃的写操作（如 Send + Flush）和一个活跃的读操作（如 Receive）同时进行，即支持“一读一写”并发，但不支持任意并发调用 Do()——因为 Do() 内部封装了完整的请求-响应流程（Send → Flush → Receive），本质上是原子性读写组合。这意味着：即使你只用 Do()，也不可将其在多个 goroutine 中无保护地共享同一连接。以下代码看似简洁，实则存在竞态风险：
var redisConn redis.Conn // ❌ 全局连接，Do() 并发调用将导致未定义行为
// 多个 goroutine 同时执行：
redisConn.Do("PUBLISH", "user:1001", msg) // 危险！
redisConn.Do("INCR", "counter") // 危险！
这类用法会引发连接状态错乱、响应错位、panic 或静默数据丢失，且难以复现和调试。
✅ 正确做法是使用 redis.Pool 管理连接生命周期。连接池本身是并发安全的，其 Get() 方法返回全新、独占、状态干净的连接，每个 goroutine 拥有独立连接上下文，彻底规避竞争：
var redisPool *redis.Pool
func initRedisPool() {
redisPool = &redis.Pool{
MaxIdle: 10,
MaxActive: 50, // 根据负载调整
IdleTimeout: 240 * time.Second,
Dial: func() (redis.Conn, error) {
c, err := redis.Dial("tcp", "localhost:6379")
if err != nil {
return nil, err
}
// 自动认证（推荐在 Dial 中完成）
if _, authErr := c.Do("AUTH", "your-password"); authErr != nil {
c.Close()
return nil, authErr
}
return c, nil
},
TestOnBorrow: func(c redis.Conn, t time.Time) error {
if time.Since(t) <p>⚠️ 注意事项：</p>
- 绝不复用连接：即使只调用 Do()，也禁止全局变量 + 多 goroutine 直接调用；Send/Flush/Receive 组合同样需独占连接。
- 务必 Close()：c.Close() 并非关闭物理连接，而是将连接归还至池中复用；遗漏会导致连接泄漏、MaxIdle 耗尽、后续 Get() 阻塞。
- Pub/Sub 需独立连接：redis.PubSubConn 必须使用专用连接（不可与命令连接混用），且应主动调用 Subscribe() 或 PSubscribe() 启动监听，示例中缺失该步骤。
- 初始化时机：连接池应在应用启动早期（如 init() 或 main() 开头）初始化，避免竞态访问未就绪池对象。
性能方面：连接池开销极小（内存复用 + TCP 连接复用），远优于每次新建 TCP 连接；相比错误的“全局连接+mutex”方案，池化设计更简洁、可靠且扩展性更强。实际压测表明，在合理 MaxIdle/MaxActive 配置下，QPS 提升显著，且无锁设计消除了 mutex 争用瓶颈。
总结：Redigo 的并发安全边界由连接实例而非方法决定——每个 goroutine 必须持有自己的连接，而连接池是达成此目标的标准、高效且健壮的解决方案。
