gqlgen生成的resolver需通过Gin的gin.WrapH包装graphql/handler.Server实例实现对接：router.POST("/query", gin.WrapH(server))，Playground须单独注册为router.GET("/playground", gin.WrapH(playground.Handler("GraphQL playground", "/query")))；resolver签名必须严格匹配generated.go中接口定义，即ctx context.Context为首位参数、返回值为(T, error)且T类型与schema完全一致，方法名大小写须与schema字段完全相同；schema变更后必须手动执行go run github.com/99designs/gqlgen generate并清理旧generated.go，同时确保gqlgen.yml中models段覆盖新增类型；所有DB调用须透传ctx，错误须用gqlerror.Errorf包装，否则导致超时失效、追踪丢失及前端无法获取结构化错误。
gqlgen 生成的 resolver 怎么和 Gin 路由对接
gqlgen 不提供 HTTP 层，它只生成 generated.go 和 resolver 接口契约。Gin 要接管请求，必须手动把 graphql/handler.NewDefaultServer 包进 gin.HandlerFunc。
关键点：不能直接注册 handler.NewDefaultServer 返回值（它是 http.Handler），而要包装成 Gin 兼容的函数：
-
router.POST("/query", gin.WrapH(server))是最简方式，server是*handler.Server实例 - 若需中间件（如 JWT 鉴权），应在
WrapH前加router.Use(authMiddleware)，不能塞在 handler 内部 - Playground 必须单独注册：
router.GET("/playground", gin.WrapH(playground.Handler("GraphQL playground", "/query")))，路径/query必须和 POST 路径一致 - 别用
router.POST("/graphql", ...)同时支持 Playground —— GraphQL 规范要求 GET 返回 UI、POST 才处理查询，混用会导致 GraphiQL 加载失败
resolver 方法签名不匹配导致 panic 怎么排查
运行时报 panic: no such method，90% 是签名与 generated.go 中接口定义不一致。gqlgen 不在编译期校验实现体，只靠反射调用。
检查清单：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 参数顺序必须是
ctx context.Context在第一位，后面才是args（如first *int） - 返回值必须是
(T, error)两值，T类型要严格匹配models_gen.go生成的 struct 指针（如[]*model.User，不是[]model.User） - schema 定义字段为非空（
User!），则返回类型必须是*model.User，不能是model.User - 方法名大小写必须和 schema 字段完全一致：
userById≠UserById，Gin 路由无关，纯 Go 接口实现问题
schema 修改后 resolver 不生效或报错
改了 schema.graphqls 但新字段没出现在 Playground 或调用报 panic，根本原因是没触发代码生成或生成结果被缓存。
实操步骤：
- 每次保存
schema.graphqls后，立刻执行go run github.com/99designs/gqlgen generate - 删掉旧的
graph/generated/generated.go再生成，避免 IDE 缓存旧文件导致 import 冲突 - 检查
gqlgen.yml的models段是否覆盖新增类型，例如新增CreateUserInput，但models没配，generated.go就不会生成对应接口 - 生成后打开
graph/generated/generated.go，确认新字段对应的 resolver 方法已出现在type QueryResolver interface中
context 未透传和错误没包装的后果
resolver 里忽略 ctx 或用 fmt.Errorf 直接返回错误，会导致超时控制失效、链路追踪丢失、前端收不到结构化错误信息。
正确做法：
- 所有 DB 调用必须用
Context版本：db.QueryRowContext(ctx, ...)、tx.CommitContext(ctx) - 错误必须用
gqlerror.Errorf或gqlerror.CustomError包装，不能return nil, fmt.Errorf(...) - 如果需要附加位置信息（line/column），用
gqlerror.ErrorWithExtensions，否则前端只看到message字段 - Gin 中间件设置的
context.WithValue可以被 resolver 读取，但别依赖全局变量传 DB 或 logger —— 并发下不安全
最容易被忽略的是：gqlgen 生成的 resolver 方法体默认是 panic(fmt.Errorf("not implemented"))，上线前必须全部替换，且每个 panic 都得换成带 ctx 和 gqlerror 的真实逻辑 —— 这一步漏掉，服务一跑就崩。
