在 Beego 中，应在每个 HTTP 请求的处理函数内调用 orm.NewOrm() 创建独立 ORM 实例，而非全局复用；此举符合框架设计逻辑，既保障并发安全，又确保事务隔离与上下文一致性，无安全风险。
在 beego 中，应在每个 http 请求的处理函数内调用 `orm.neworm()` 创建独立 orm 实例，而非全局复用；此举符合框架设计逻辑，既保障并发安全，又确保事务隔离与上下文一致性，无安全风险。
Beego 的 orm.NewOrm() 并非直接建立物理数据库连接，而是初始化一个轻量级的 ORM 上下文对象（Orm 实例），该实例内部持有一个线程/协程安全的连接池引用，并绑定当前 Goroutine 的执行上下文。它负责管理模型映射、SQL 构建、参数绑定、事务状态及数据库别名路由等逻辑。
因此，在控制器方法中按需创建是推荐且必需的做法：
func (c *UserController) Get() {
o := orm.NewOrm() // ✅ 正确：每次请求新建实例
var users []User
_, err := o.QueryTable("user").All(&users)
if err != nil {
c.Data["json"] = map[string]interface{}{"error": err.Error()}
c.ServeJSON()
return
}
c.Data["json"] = users
c.ServeJSON()
}⚠️ 切勿这样做（反模式）：
// ❌ 错误：全局单例 orm 实例
var globalOrm orm.Ormer
func init() {
globalOrm = orm.NewOrm() // 危险！共享状态导致并发冲突、事务污染、上下文错乱
}关键原因如下：
- 并发安全性：Beego 的 ORM 实例不是 goroutine 安全的共享对象。多个请求共用同一实例可能导致 QuerySeter 链式调用状态污染（如 Filter().OrderBy().Limit() 等中间状态被交叉覆盖）；
- 事务隔离性：每个请求可能开启独立事务（o.Begin() → o.Commit()/o.Rollback()）。复用实例会使事务控制失效，甚至引发 sql: transaction has already been committed or rolled back 等 panic；
- 数据库路由可靠性：虽可通过 o.Using("otherdb") 切换库，但该设置属于实例级状态；若全局复用并动态切换，极易造成后续请求误连非预期数据库；
- 资源生命周期匹配：HTTP 请求有明确的起止边界，ORM 实例的生命周期应与之对齐，便于框架自动清理临时查询上下文和延迟释放连接。
✅ 优化提示：若仅使用默认数据库，可省略 o.Using("default") —— NewOrm() 默认即指向配置中的 "default" 数据源。
总结：orm.NewOrm() 是廉价、无副作用的上下文构造操作，性能开销可忽略（实测单次耗时 < 0.1μs）。坚持“每请求一实例”原则，既是 Beego ORM 的设计契约，也是构建高可靠 Web 服务的底层保障。
