Beego ORM v2.0.0默认不支持读写分离，仅允许注册一个主数据库连接；需手动通过Using方法指定数据库别名，并配合控制器生命周期或工具函数实现读写路由，但易绕过事务控制且存在主从延迟导致刚写入就读不到的问题。
Beego ORM 默认不支持读写分离
Beego v2.0.0 内置的 orm 组件没有原生的读写分离（read-write split）能力。它只允许注册一个主数据库连接，所有 Insert、Update、Delete 和默认 Read 操作都走同一连接。强行在应用层手动切库，容易绕过 ORM 的事务控制和模型生命周期管理。
必须手动接管 QueryTable 的数据库选择逻辑
要实现读写分离，核心是让写操作固定走 master，而读操作（如 All、One、Count）可路由到 slave。Beego ORM 提供了 Using 方法指定数据库别名：
// 写操作强制走 master
o := orm.NewOrm()
o.Using("default") // 假设 "default" 是你配置的 master 别名
o.Insert(&user)
// 读操作显式走 slave
o2 := orm.NewOrm()
o2.Using("slave1")
o2.QueryTable("user").Filter("status", "active").All(&users)
常见踩坑点：
- 忘记在
models.RegisterModel后调用orm.RegisterDataBase注册多个数据库别名（如"default"和"slave1"） - 在事务中混用
Using("slave1")—— 从库无法执行事务，会直接 panic - 使用
RelatedSel时未同步指定Using，导致关联查询仍走主库 - 没重写
QuerySeter的Values/ValuesList等方法，它们内部不继承Using设置，需显式传参
读写分离不能只靠 ORM 层，得配合中间件或路由策略
纯 ORM 层硬切库会导致业务代码大量侵入 Using("slave1")，维护成本高。更可行的做法是结合 Beego 的控制器生命周期做轻量路由：
- 在
Prepare方法中根据 HTTP 方法判断：若为GET或HEAD，则将当前Controller.Ctx.Input.Data["db"]设为"slave1"；其余方法设为"default" - 封装一个
GetDB()工具函数，统一返回当前上下文应使用的数据库别名 - 避免在
Init阶段全局替换orm.DefaultOrmer，这会破坏并发安全 - 注意健康检查：从库延迟或宕机时，需有 fallback 机制（比如降级到主库读），否则
500错误会直接暴露给前端
Beego + MySQL 主从延迟场景下，刚写入就读不到
这是读写分离最典型的副作用。例如用户注册后立即跳转到个人页，却查不到刚创建的记录。根本原因是 MySQL 主从复制存在毫秒级延迟，而 Beego ORM 不提供“强一致性读”开关。
应对方式只有两个方向：
- 对关键路径（如注册后跳转、支付结果页）主动走主库读：
orm.NewOrm().Using("default").QueryTable(...) - 在从库查询前加简单重试逻辑（最多 2 次，间隔 50ms），但仅适用于非高频接口，否则放大从库压力
- 不要依赖
auto_now_add或auto_now字段做读写判断依据——它们在从库回放时才写入，时间戳本身就不一致
真正难处理的是跨服务场景：比如订单服务写完发 MQ，库存服务从从库读取订单状态，这时必须接受最终一致性，或改用分布式事务协调器（如 Seata Go 客户端），Beego ORM 层对此无能为力。
