gqlgen是Go生态唯一可落地的GraphQL方案：先执行gqlgen init生成骨架，再运行gqlgen generate生成强类型代码，resolver业务逻辑须严格匹配接口签名，依赖注入推荐dig，N+1问题需DataLoader解决。
用 gqlgen 初始化 GraphQL 服务骨架
直接生成可运行的强类型服务，不是从零手写 schema 和 resolver。gqlgen 是 Go 生态里最主流的选择，它把 schema.graphqls 和 Go 类型绑定得足够紧，避免运行时字段错配。
执行这两步就能跑起来：
-
go run github.com/99designs/gqlgen init—— 自动生成graph/schema.graphqls、graph/generated/generated.go和graph/resolver.go -
go run github.com/99designs/gqlgen generate—— 每次改完schema.graphqls后必须执行，否则 resolver 接口和模型不匹配
常见坑：改了 schema 但忘了 generate，编译会报 missing method XXXResolver；或者 resolver.go 里手动改了函数签名，结果被下次 generate 覆盖掉 —— 所有业务逻辑只写在 Resolver 方法体里，别碰函数声明。
resolver 中如何安全注入依赖（比如数据库、缓存）
硬编码 db := sql.Open(...) 在 resolver 里会导致测试难、复用差、连接泄漏。Go 里推荐用依赖注入容器，dig 是目前最轻量且契合 GraphQL 执行模型的方案。
立即学习“go语言免费学习笔记（深入）”；
关键点在于：resolver 实例本身不持有依赖，而是通过 dig 容器在每次请求时按需解析依赖图。
- 注册依赖：
container.Provide(func() *sql.DB { return dbConn }) - 注入到 resolver：
container.Invoke(func(r *Resolver) { /* r.db = ... */ })，或更推荐用构造函数注入，在NewResolver里接收*sql.DB - 注意生命周期：HTTP handler 创建 resolver 实例时，应确保每个请求拿到的是干净的实例；若用单例 resolver，务必保证其字段（如
db）是线程安全的
别把 context.Context 当作依赖塞进 dig —— 它属于请求上下文，应该由 resolver 方法参数传入，而不是容器注入。
避免 N+1 查询：DataLoader 必须配合批处理实现
GraphQL 嵌套查询（比如 { users { posts { author } } }）天然容易触发 N+1 数据库查询。光靠加缓存或预加载（eager load）不够，必须用 DataLoader 模式做批处理合并。
gqlgen 官方不内置 DataLoader，得自己集成或用第三方库（如 vektah/gqlgen-contrib/dataloader）。核心逻辑是：
- 在 resolver 中调用
loader.Load(ctx, id)，它返回一个func() (T, error)异步闭包 - 同一请求周期内所有
Load调用会被收集，等 resolver 执行完一层后统一触发一次批量查询（如SELECT * FROM posts WHERE id IN (?, ?, ?)） - 错误处理要显式包裹：不能让单个
Load失败导致整个查询崩溃，要用result.ErrorOrNil()判断
容易忽略的细节：DataLoader 实例必须按请求生命周期创建（比如放在 context.WithValue 里），不能全局复用，否则不同请求的数据会混在一起。
HTTP 端点怎么暴露才符合生产要求
GraphQL 不强制要求 HTTP 方法，但实际部署中，POST /graphql 是事实标准。别用 GET 传大 query 字符串，URL 长度有限制，且无法带 variables。
- Content-Type 必须是
application/json，且 body 结构要严格匹配：{"query":"...","variables":{}} - 别自己写
http.HandleFunc处理逻辑 —— 用gqlgen/handler.GraphQL，它自带 introspection 开关、playground 支持、复杂度限制等安全控制 - 生产环境务必关闭
handler.Playground，并用中间件校验ctx.Value中的 auth token 或 JWT
真正麻烦的不是写 endpoint，而是后续的可观测性：query 执行时间、深度、字段命中率这些指标，得靠 graphql-go/graphql 的 Instrumentation 或 OpenTelemetry 插桩，否则线上出问题根本没法定位是哪个字段拖慢了整条链路。
