多中心机房下gorm读库路由必须显式绑定地理位置，需为各机房从库单独创建*gorm.db实例（如hzslavedb、shslavedb），通过请求上下文透传region并由getreaddb(ctx)动态返回对应地域从库，禁止共用连接池或依赖dbresolver默认轮询，确保读写同地域以避免脏读与超时。
多中心机房下 GORM 的读库路由必须显式绑定地理位置
单纯靠 dbresolver 插件的轮询或权重策略，无法满足跨机房读流量调度需求。GORM 默认的 replicas 是扁平列表，不携带位置元信息，一旦杭州机房从库延迟升高或网络抖动，请求仍可能被分发过去，造成查询超时或脏读。
真实场景中，你需要让每个 *gorm.DB 实例明确知道自己服务哪个区域：
- 初始化时为每个机房的从库单独创建
*gorm.DB，例如hzSlaveDB、shSlaveDB、szSlaveDB - 在 HTTP 请求上下文（如 Gin 的
c.Request.Context()）中透传用户归属地（通过 Header、GeoIP 或用户 profile） - 封装一个
GetReadDB(ctx context.Context) *gorm.DB函数，根据ctx.Value("region")返回对应机房的从库实例，而不是调用dbresolver的全局Reader - 避免在中间件里缓存
*gorm.DB实例——不同请求的 region 可能不同，复用会导致路由错乱
主库写入后从库读不到？不是延迟问题，是路由没对齐
常见现象：用户刚提交订单（走杭州主库），紧接着查订单列表却返回空（查了深圳从库）。这不是主从复制延迟导致的，而是读写路由完全脱离了“同地域优先”原则。
关键约束必须守住：
- 写操作必须走用户所在地域的主库（如杭州用户 → 杭州主库），否则后续读请求即使路由正确，也查不到刚写入的数据（跨地域主从延迟通常 > 500ms）
- 读请求必须与写请求落在同一地域的主从集群内，即“写在哪，读就去哪的从库”，不能写杭州、读上海
- GORM 的
Transaction内所有操作自动走sources，但事务结束后，后续的Find若未显式指定上下文 region，会 fallback 到默认replicas列表，极易跨地域 - 别依赖
db.Session(&gorm.Session{Context: ctx})试图传递地域信息——Session不影响dbresolver的路由决策
连接池不能共用，每个机房从库要独立调优
杭州、上海、深圳三地从库的硬件配置、网络 RTT、负载水位完全不同，共用一个连接池参数只会让部分机房过载或闲置。
实操要点：
- 每个机房的
*gorm.DB实例调用独立的SetMaxOpenConns和SetConnMaxLifetime，例如杭州从库设120，深圳旧机器设40 - 必须对每个从库实例单独执行
hzSlaveDB.Exec("SELECT 1")或hzSlaveDB.Raw("SELECT 1").Scan(nil)做连通性验证，不能只 ping 主库 - 不要把所有从库 DSN 写进同一个
dbresolver.Register()调用里——这会让 GORM 把它们当同质节点轮询，失去地域隔离能力 - 监控每个从库的
sql.DB.Stats().OpenConnections，发现某地连接数长期占满，说明该地连接池配置偏低或存在连接泄漏
为什么 dbresolver 的 Weighted 策略在这里基本失效
dbresolver 的权重是静态配置在代码里的，而多中心架构下的真实负载是动态变化的：杭州机房可能因大促流量突增，上海机房因专线故障带宽只剩 30%，此时硬编码的权重值毫无意义。
更可行的做法是：
- 放弃
dbresolver的内置权重，改用运行时决策：在GetReadDB(ctx)中调用轻量健康检查接口（如各机房从库暴露的/health?role=slave），根据响应时间、错误率动态选择 - 对高一致性要求的读（如订单详情），强制走写入同地域的从库；对低一致性要求的读（如商品浏览），才考虑 fallback 到其他机房
- 如果用了 Consul 或 Nacos，可将从库的 region、weight、latency 挂为服务元数据，客户端定期拉取并构建本地路由表
- 切记：权重永远不该是“杭州 50%、上海 30%、深圳 20%”这种固定比例，而应是“杭州可用、上海延迟 > 200ms、深圳不可用”这类状态判断
跨机房读负载均衡最难的不是代码怎么写，而是如何让每一次读请求都清楚自己“该去哪”，以及当“该去的那台”不可用时，有没有安全、可控的降级路径。静态配置和通用插件在这里都会迅速失焦。
