Gin框架本身不提供主从数据库自动切换能力，因其中间件仅作用于HTTP请求生命周期，无法干预database/sql连接池的底层行为；*sql.DB配置不可变、连接目标无法运行时替换、事务绑定具体连接，故不能靠中间件实现主从切换。
Gin 框架本身不提供主从数据库自动切换能力，所谓“动态切换”必须由上层逻辑控制——核心在于连接池管理、读写分离路由、故障感知与连接重建，而不是 Gin 自身功能。
为什么不能靠 Gin 中间件做主从切换
Gin 的中间件只处理 HTTP 请求生命周期，无法干预 database/sql 连接池的底层行为。你不能在 c.Next() 里“把当前正在用的 *sql.DB 换成另一个实例”，因为：
- Go 的
*sql.DB是线程安全但不可变配置的连接池，创建后SetMaxOpenConns等参数可调，但 DSN、驱动、底层连接目标无法 runtime 替换 - 已建立的连接不会自动重定向；切换主库地址后，旧连接仍连原地址，直到被回收或超时
- 事务上下文（
*sql.Tx）绑定到具体连接，跨库切换会直接 panic
实际可行的主从路由方案：基于 sqlx 或 gorm 的读写分离封装
主流做法是封装一个统一的数据库访问层，在执行前根据 SQL 类型（SELECT vs INSERT/UPDATE/DELETE）或显式标记（如 db.WithContext(context.WithValue(ctx, db.RoleKey, db.Slave))）分发到不同 *sql.DB 实例：
- 主库实例：只用于写操作，配置
write_timeout和重试策略应对短暂不可用 - 从库实例：可配多个，用简单轮询或权重路由；需开启
read_only=1并监控复制延迟（Seconds_Behind_Master） - 切换触发点：仅限主动降级（如运维手动切流）、或检测到主库连续
3次连接失败后，将写请求暂存队列 + 返回降级响应，而非“自动切到从库执行写操作”——后者违反一致性
示例伪代码（使用 sqlx）：
func (d *DBRouter) QueryRow(ctx context.Context, query string, args ...interface{}) *sqlx.Row {
if isWriteSQL(query) {
return d.master.QueryRowContext(ctx, query, args...)
}
return d.slavePool.Get().QueryRowContext(ctx, query, args...)
}
主库故障时的连接重建与缓存失效
真正需要“动态”的地方，是连接池对故障的响应和恢复，而非 SQL 路由逻辑本身：
- 主库宕机后，
driver.Open会报错（如dial tcp: i/o timeout），此时应立即标记该连接池为不可用，并触发告警 - 不要静默 fallback 到从库执行写操作；而应在 API 层返回
503 Service Unavailable，前端/客户端按退避策略重试 - 恢复检测建议用独立 goroutine 定期 ping 主库（
db.PingContext），成功后清除故障标记，而非依赖首次写请求失败才尝试重连 - 若使用 Redis 缓存（如 gin-vue-admin 的
global.GVA_REDIS），主库故障期间应禁用涉及写操作的缓存更新，避免脏数据
复杂点不在 Gin，而在你如何定义“切换”——是读流量调度？还是写失败兜底？前者可控，后者基本不可行。多数线上系统把“主库不可写”视为 P0 故障，走预案而非自动切换。
