可行但需手动管理schema、resolver和解析逻辑；常见问题包括graphql.do因requeststring或schema缺失返回空/panic，resolver签名不符或类型不匹配，以及gin context未透传导致下游调用丢失超时与追踪。
直接用 graphql-go + gin 搭 GraphQL 接口，不引入额外工具链（如 gqlgen），是可行的，但必须手动管理 schema 定义、 resolver 绑定和请求解析逻辑——稍有疏忽就会返回空响应或 panic。
为什么 graphql.Do 总是返回空或 panic？
这是最常见卡点：你用了 graphql-go 的执行函数，但没正确传入 RequestString 或 Schema，或者 resolver 返回值类型不匹配 schema 声明。
-
graphql.Do要求RequestString必须是完整 GraphQL 查询字符串（不能是 JSON body 里嵌套的字段）；Gin 默认用c.PostForm("query")只能取 form-data，对 JSON 请求会失效 - resolver 函数签名必须严格为
func(p graphql.ResolveParams) (interface{}, error)，返回值类型要和 schema 中Type一致（比如字段声明为graphql.String，就不能返回*string） -
Schema初始化失败时，graphql.NewSchema返回的是nil和 error，但很多示例代码直接忽略 error，导致后续graphql.Dopanic
handler.New 和手写 graphql.Do 该怎么选？
二者本质不同：handler.New 是封装好的 HTTP handler，自动处理 POST/GET、GraphiQL 页面、JSON 解析；而 graphql.Do 是纯执行层函数，需要你手动解析请求体、构造 graphql.Params。
- 开发调试阶段优先用
handler.New：它内置GraphiQL:true，GET 请求可直接打开可视化界面，POST 请求自动从 JSON body 的"query"字段读取内容 - 生产环境若需精细控制（如加 trace、统一错误格式、拦截特定字段），才改用手动
graphql.Do，但必须自己解析c.GetRawData()并 JSON Unmarshal - 注意：
handler.New不支持自定义 context（比如带 auth info 的context.Context），resolver 里拿不到 Gin 的*gin.Context，得靠handler.Config.Context传入
Gin 路由里怎么安全注册 GraphQL endpoint？
别只挂一个 POST，否则 GraphiQL 界面打不开，前端调试困难；也别把 GET 和 POST 指向不同 handler，容易漏配。
- 必须同时注册
GET和POST到同一 handler，且 handler 要能区分请求方法：handler内部已实现该逻辑 - 路径别用
/graphql就完事——如果项目已有 REST v1/v2 版本，建议统一前缀，例如/api/v1/graphql，避免网关路由冲突 - 不要在 handler 里直接调
c.Next()或写 header，handler已全权接管 response 流程；强行干预会导致 Content-Type 错误或重复 write
真正麻烦的不是写几行 resolver，而是 resolver 里要访问数据库或调下游服务时，如何把 Gin 的 *gin.Context 透传进去——graphql-go 的 ResolveParams 里只有 Context 字段，它默认是 context.Background()，不是 Gin 的 context。这个细节几乎没人提，但线上出问题时第一个排查点就是它。
