beego本身不内置graphql支持，必须集成gqlgen等第三方库；直接用beego.router挂载gqlgen handler会绕过中间件链、丢失上下文透传与错误处理能力；正确方式是将gqlgen.server嵌入自定义graphqlcontroller，复用beego生命周期与ctx.input数据。
Beego 本身不内置 GraphQL 支持，必须手动集成第三方库（如 gqlgen）才能提供 GraphQL 接口。直接在 Beego 的 Controller 里写 graphql.Serve 是常见但危险的起点——它绕过了 Beego 的中间件链、日志上下文和请求生命周期管理。
为什么不能直接用 beego.Router 挂载 gqlgen HTTP handler
Beego 的路由系统基于基数树（Radix Tree），而 gqlgen 默认暴露的是标准 http.Handler。若直接用 beego.Router("/graphql", &GraphQLHandler{}, "*:ServeHTTP")，会触发两个关键问题：
-
beego.Controller的Prepare()、Finish()不会被调用，丢失统一鉴权、日志记录、响应头注入等能力 - Beego 的上下文（
ctx.Input）与gqlgen的context.Context完全隔离，无法透传 trace ID、用户信息或数据库事务对象 - 错误处理机制断裂：Beego 的
Abort()和CustomAbort()对gqlgen内部 panic 无效，错误堆栈不会进入 Beego 日志系统
正确集成方式：把 gqlgen handler 嵌入 beego.Controller
核心思路是让 gqlgen 的 http.Handler 成为 Beego 控制器的一个方法，复用 Beego 的请求上下文。需三步落地：
- 定义一个继承自
beego.Controller的GraphQLController，并在其中持有*gqlgen.Server实例（通常在Init()或Prepare()中初始化） - 重写
GraphQLController.ServeHTTP()方法，将beego.Controller.Ctx.ResponseWriter和beego.Controller.Ctx.Request转为标准http.ResponseWriter和*http.Request，再交由gqlgen.Server处理 - 在
router.go中注册：beego.Router("/graphql", &controllers.GraphQLController{}, "post:ServeHTTP;get:ServeHTTP")
这样所有 Beego 中间件（如 JWT 鉴权、CORS、请求耗时统计）都能作用于 GraphQL 请求，且 ctx.Input.Data 可安全注入到 gqlgen.Resolver 的 context.Context 中。
Resolver 中如何安全获取 Beego 的数据库 ORM 实例
gqlgen 的 resolver 函数签名固定为 func(context.Context, *model.Args) (*model.Result, error)，无法直接访问 Beego 的 orm.Ormer。常见错误是全局单例初始化 ORM，导致并发下连接泄漏或事务混乱。
- 正确做法是在 Beego 的
Prepare()中初始化本次请求专属的orm.Ormer，并存入ctx.Input.Data["orm"] - 在
GraphQLController.ServeHTTP()调用前，确保已执行c.Prepare()（Beego 自动调用，但需确认未被跳过） - resolver 中通过
ctx.Value("orm")或封装的 helper 函数（如GetORM(ctx)）提取该实例，避免跨请求复用 - 务必在
Finish()或 defer 中显式调用orm.Close()（如果使用了事务）或释放连接池资源
Schema 设计时必须避开 Beego 的路径冲突习惯
Beego 默认支持 RESTful 路由如 /api/users/:id，而 GraphQL 通常只用一个端点 /graphql。但开发者常误在 Schema 中定义类似 type User { id: ID! path: String! }，然后在 resolver 里拼接 /api/users/123 去调用自身服务——这会造成循环代理、超时雪崩。
- GraphQL Resolver 应直接操作本地 ORM 或调用 domain service，而非反向 HTTP 请求本服务
- 若必须调用其他微服务，应走独立 client（如
http.Clientwith timeout），且禁用 Beego 的HttpClient（它默认共享 Beego 全局配置，易受中间件干扰） - 避免在
schema.graphql中暴露与 Beego 路由同名的字段（如path,method,query），防止 resolver 逻辑与框架语义混淆
最易被忽略的是 resolver 中 context 的生命周期——它随 GraphQL 查询树深度变化，不是每个字段 resolver 都能拿到完整 Beego 上下文；若依赖 ctx.Input.Session，需在顶层 query resolver 中提前解包并显式传递。
