主备切换需保障故障下请求不丢、路由不错、降级可控；go微服务中须解耦“谁是主”“怎么切”“切后是否稳”，grpc需region-aware fallback、repository层直控主从、配置兜底含哈希校验、备份独立goroutine闭环。
主备切换不是“换个地址连上就行”，而是要在连接断开、数据不一致、状态未同步等真实故障下，仍能保证请求不丢、路由不错、降级可控。Go 微服务里做主备切换，核心是把“谁是主”“怎么切”“切了之后还稳不稳”这三件事拆开控制，而不是堆一个开关就完事。
gRPC 客户端必须支持 region-aware fallback 而非简单重连
很多团队用 grpc.WithBlock() + grpc.FailOnNonTempDialError(true) 实现“失败即切”，结果发现主 Region 网络抖动时，客户端直接卡死在 dial 阶段，根本没机会 fallback。
- 禁用
grpc.WithBlock()：它会让grpc.Dial阻塞直到连接建立或超时，而主备切换需要的是“快速失败 + 快速尝试备选” - 用自定义
resolver.Builder，在Build()阶段根据context中的region标签（比如从 HTTP Header 或 gRPC Metadata 解析）动态生成 Target，而非靠 DNS 或静态配置 - fallback 不是盲跳：调用
/health?region=sh接口获取返回值{"region":"sh","upstream":{"bj":false,"hz":true}}，只切到标记为true的 region；避免因网络分区误判导致双写 - 首次连接失败后，立刻读取本地缓存的 region 路由表（JSON 文件），不等配置中心恢复——否则启动阶段就 503
数据库主从切换必须绕过 ORM 层直控 Repository
ORM（如 GORM）自带的读写分离插件通常只做简单负载均衡，无法感知主库是否真正宕机，也做不到事务内强制走主库。一旦主库假死（TCP 连接通但 SQL 执行 hang），所有写操作会持续失败。
- 在
Repository层显式区分masterDB和slaveDB实例，不要共用同一个*sql.DB - 写操作必须通过
masterDB执行，并在执行前调用masterDB.PingContext(ctx)；失败则触发主库健康检查逻辑，而非直接 panic - 主库不可用时，不能自动把写请求转给某个从库——这是数据一致性灾难；应立即进入只读降级模式，并上报告警
- 主从切换决策由独立的
failover-controllergoroutine 统一管理，通过 etcd watch 主库心跳，变更后更新共享的atomic.Value存储当前 master 地址，Repository 层只读取该值
配置中心失效时，本地兜底必须含内容哈希校验
用 viper.WatchConfig() 监听配置变更，在容器环境里极不可靠：fsnotify 在 overlayfs/NFS 上常失效，导致配置更新不生效却无报错；更糟的是，有人用 os.FileInfo.ModTime() 判断文件是否更新，结果 CI/CD 打包时时间戳变了但内容没变，服务误加载脏配置。
- 改用
time.Ticker每 10 秒轮询配置文件，读取后计算sha256.Sum256哈希值，仅当哈希变化才解析 - 兜底 JSON 文件必须和代码一起发布，不能靠运行时下载——否则容器启动时网络不通就彻底没配置
- 所有配置字段必须封装进一个 struct，用
atomic.Value.Store(&config, &newConfig)原子替换，禁止用sync.Map分散存 key，否则并发读时出现部分字段新、部分旧 - 配置项里必须带
meta.version字段（如"20260706-1001"），便于排查哪次变更实际生效
备份任务必须独立 goroutine + 超时 + 校验码闭环
把 os.Open + io.Copy 放在 handler 里执行，等于把用户请求和备份 IO 绑定在一起；一次磁盘慢 IO 就拖垮整个接口。更危险的是，备份中途失败却不清理临时文件，下次再跑就覆盖或冲突。
- 备份逻辑必须在独立 goroutine 中执行，且绑定
context.WithTimeout(ctx, 30*time.Second)，超时立即return - 打开文件后立刻
defer f.Close()；数据库备份前先db.PingContext()，失败直接退出，不重试 - 备份完成后生成
sha256.Sum256校验码，和备份文件一起上传到异地对象存储；恢复时先比对哈希，再解压还原 - 不要用
time.Sleep控制频率，用time.Ticker+select配合 context 取消，避免 goroutine 泄漏
主备切换最难的不是代码写几行，而是每个环节都要回答一个问题：“如果这个组件挂了，下游会不会跟着崩？”——Region 感知失效、配置中心失联、主库假死、备份 IO 卡住……这些都不是异常场景，而是常态。容灾方案真正的复杂点，在于你得提前想好每一层“挂了之后谁来兜底”，而不是等报警响了再查日志。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
