beego 不原生支持 graphql，需通过 gqlgen 集成并手动接管路由；必须用 beego.handler("/graphql", graphqlhandler) 替代 router，启用 copyrequestbody，并在 resolver 中安全复用 orm.ormer 实例，显式处理事务与错误。
Beego 本身不原生支持 GraphQL，必须通过第三方库（如 gqlgen）集成，且需手动接管 HTTP 路由和请求生命周期 —— 这是所有 Beego + GraphQL 项目绕不开的第一道坎。
为什么不能直接用 beego.Router 注册 GraphQL 端点
Beego 的 beego.Router 设计面向 RESTful 的方法级路由（如 "get:List"），而 GraphQL 只暴露一个统一端点（通常是 /graphql），所有查询、变更都走 POST，靠请求体中的 query 字段区分操作。直接用 Router 绑定会丢失对 variables、operationName 的解析能力，也无法透传上下文（如认证信息、trace ID）给 gqlgen 的 Resolver。
正确做法是：用 beego.Handler 或自定义 Controller 拦截原始 *http.Request，再交由 gqlgen 的 http.HandlerFunc 处理：
- 在
main.go中调用beego.Handler("/graphql", graphqlHandler)，其中graphqlHandler是gqlgen生成的http.HandlerFunc - 若需注入中间件（如 JWT 验证），必须在
graphqlHandler之前 wrap 一层，不能依赖 Beego 的Filter，因为gqlgen不走 Beego 的 Controller 生命周期 - 注意设置
beego.BConfig.CopyRequestBody = true，否则gqlgen读不到 POST body
schema.graphql 中的 Query/Mutation 类型如何映射到 Beego Model
GraphQL 的 Query 和 Mutation 是逻辑操作入口，不是数据结构；Beego 的 models.User 才是真实 ORM 映射。二者之间没有自动绑定关系，必须手动在 Resolver 中调用 Beego ORM。
常见错误是试图让 gqlgen 自动生成 Model 结构体，结果和 Beego 的 models.User 冲突，导致数据库操作失效。正确路径是：
- 保持 Beego 的
models.User不变，含TableName()、PK()等 ORM 标签 - 在
graph/resolver.go的Query.Users方法里，显式调用o.QueryTable("user").All(&users) - 如果字段名不一致（如 GraphQL 字段叫
fullName，Model 字段叫Name），在 Resolver 返回前做一次字段映射，不要改 Schema 或 Model
resolver 中如何安全复用 Beego 的 orm.Ormer 实例
Beego 的 orm.NewOrm() 默认返回全局单例，但在高并发下可能因事务未关闭导致连接泄漏或脏读。GraphQL 请求常带多个嵌套字段（如 user { orders { items } }），每个 Resolver 层级都新建 Ormer 会放大问题。
推荐方式是：在每次 GraphQL 请求开始时，从 Beego 的 context.Context 中提取或创建一个带事务的 orm.Ormer，并透传至所有 Resolver：
- 在
graphqlHandler中，用orm.NewOrmWithDB创建带连接池的实例，或用o.Begin()启动事务 - 将该实例存入
graphql.ResolverContext的ctx.Value，各 Resolver 通过ec.Context().Value(...)获取 - 务必在请求结束时调用
o.Commit()或o.Rollback()，可用defer+recover保底
最易被忽略的是错误处理粒度：GraphQL 要求部分字段失败时仍返回其他字段结果，但 Beego 的 o.Read() 报错会直接中断整个 Resolver。必须把每个数据获取逻辑包在 try/catch（Go 里是 if err != nil）中，并返回 nil + 错误，而非 panic。
