Iris框架不内置GraphQL支持，需手动集成graphql-go等库：通过ctx.ReadJSON解析请求体，桥接iris.Context到graphql.Context，并透传DB/session等依赖至resolver。
Iris 框架本身不内置 GraphQL 支持，它没有像 Spring GraphQL 或 rebing/graphql-laravel 那样的开箱即用解析器和执行器。你要在 Iris 中处理 GraphQL 查询，必须手动接入第三方 GraphQL 服务层（如 graphql-go 或 gqlgen），并自行桥接 HTTP 请求与 GraphQL 执行流程。
GraphQL 请求体怎么被 Iris 正确读取？
GraphQL 客户端通常以 POST /graphql 发送 JSON，请求体形如：
{"query":"{ user(id: 1) { name } }", "variables": {} }。Iris 默认不会自动解析这个 JSON 体——你得显式调用 ctx.ReadJSON() 或 ctx.ReadBody()。
常见错误是直接用 ctx.FormValue("query")：这完全无效，因为 GraphQL 不走表单编码，也不把 query 当 URL 参数传；它只走请求体的 JSON 字段。
- 必须用
ctx.ReadJSON(&req)，其中req是你定义的结构体，含Query、Variables、OperationName字段 - 别用
map[string]interface{}接整个 body——类型丢失，后续传给 GraphQL 执行器时会 panic 或静默失败 - 如果前端发的是
application/graphql（纯字符串查询），就得用ctx.ReadBody()+string()转换，再手动补全variables等字段
怎么把 Iris 请求交给 graphql-go 执行？
graphql-go 是 Go 生态较成熟的 GraphQL 实现，但它的 graphql.Do 函数需要 *graphql.Context 和已编译的 *graphql.Schema，不直接认 Iris 的 context.Context 或 iris.Context。
关键点在于桥接：
- 先用
graphql.ParseSchema(schemaStr, nil)一次性加载你的 Schema（建议在应用启动时做，别每次请求都 parse） - 构造
graphql.Params：把从ctx.ReadJSON解出的Query、Variables、OperationName填进去 -
params.Context = context.WithValue(ctx.Request().Context(), "iris_ctx", ctx)—— 把 Iris 上下文透传进去，供 resolver 访问数据库或 session - 执行
graphql.Do(params)，结果是graphql.Result，需手动序列化回 JSON 响应
resolver 怎么拿到 Iris 的数据库连接或 session？
GraphQL resolver 函数签名通常是 func(p graphql.ResolveParams) (interface{}, error)，它拿不到 iris.Context。所以你不能在 resolver 里直接调 ctx.DB() 或 ctx.Session().GetInt("uid")。
正确做法是利用 params.Context 透传的值：
- 在
graphql.Do前，把必要依赖塞进 context：params.Context = context.WithValue(params.Context, "db", myDB)
- 在 resolver 里取出：
db := params.Context.Value("db").(*sql.DB) - Session 更复杂些：Iris session 不是线程安全的，不能直接存进 context；建议改用中间件提前解出用户 ID，存为
"user_id"key，resolver 只读 ID 再查库
为什么不用 gqlgen？它和 Iris 兼容吗？
gqlgen 是代码生成型工具，它生成的 handler 是标准 http.Handler，可以被 Iris 的 iris.WrapHandler 包裹，但代价不小：
- 你需要额外起一个子路由（比如
app.Post("/graphql", iris.WrapHandler(generatedHandler))） - gqlgen 生成的 resolver 依赖
context.Context，你仍要手动注入 Iris 特有对象（DB、session、logger） - gqlgen 强绑定
github.com/99designs/gqlgen/graphql/handler，而 Iris 的中间件链和错误处理机制与之不兼容——比如 Iris 的ctx.StatusCode(401)在 gqlgen handler 里不会生效，得靠 gqlgen 自己的 error format 返回
简单项目不如直接用 graphql-go 手动桥接；中大型项目若坚持用 gqlgen，建议剥离 Iris，改用标准 net/http 启服务，再用反向代理把 /graphql 路由过去——反而更稳。
GraphQL 在 Iris 里不是“配个中间件就跑”，核心难点永远在上下文传递和错误映射：resolver 抛的 error 怎么转成 Iris 能统一拦截的格式？400 错误是返回 GraphQL 标准错误对象，还是 Iris 的 JSON 错误模板？这些边界不厘清，调试时会卡在“请求没报错但返回空”这种静默失败上。
