用 graphql-go 启动 GraphQL 服务需三步：手写 schema、实现 Resolve 函数、用 http.HandlerFunc 封装 graphql.Do；须检查 result.Errors 而非直接序列化；依赖通过 p.Info.RootValue 透传，不可全局存储；不支持订阅因无 WebSocket 实现。
用 graphql-go 启动一个可运行的 GraphQL 服务
Go 里最轻量、最贴近原生 HTTP 的 GraphQL 实现是 graphql-go/graphql，它不带自动路由或 schema 生成，但正因如此，你不会被框架魔改请求生命周期。启动一个基础服务只需三步：
- 定义
schema（必须手写，不能靠 struct tag 自动生成） - 实现
Resolve函数，处理每个字段的取值逻辑 - 用
http.HandlerFunc包一层，把 POST body 解成graphql.Params，再交给graphql.Do
常见错误是直接把 graphql.Do 返回结果原样 json.Marshal 后写回响应——漏了检查 err 和 result.HasErrors()，导致前端只收到空对象却无报错提示。正确做法是显式判断 result.Errors 并返回标准 GraphQL 错误结构。
resolver 中怎么传 context 和依赖？
graphql-go 的 Resolve 函数签名固定为 func(p graphql.ResolveParams) (interface{}, error)，没法直接塞 context.Context 或数据库句柄。真实项目里必须靠 p.Info.RootValue 透传——它是个 interface{}，通常设成 map 或 struct。
- 启动时：在
http.HandlerFunc里构造graphql.Params{RootValue: map[string]interface{}{"db": db, "ctx": r.Context()}} - resolver 内：用类型断言取出
db := p.Info.RootValue.(map[string]interface{})["db"].(*sql.DB) - 注意：
RootValue是每次请求独享的，不是全局单例，所以可以安全塞 request-scoped 的context
容易踩的坑是把 DB 连接池或 logger 直接塞进 schema 全局变量——并发下会 panic，因为 graphql-go 不保证 resolver 调用时的 goroutine 安全边界。
立即学习“go语言免费学习笔记（深入）”；
为什么 graphql-go 不支持订阅（subscription）？
它压根没实现 WebSocket 协议层，也不提供 Subscribe 字段注册机制。想做实时推送，得自己搭 gorilla/websocket 服务，再手动把 GraphQL 查询解析、执行、变更通知三块拼起来。
- 简单场景：用
pubsub模式（如github.com/lib/pq的 LISTEN/NOTIFY）触发重查，再推 JSON 结果 - 复杂场景：需要维护 client → subscription ID → channel 映射表，且必须处理连接断开后的 cleanup，否则 goroutine 泄漏
- 兼容性影响：所有前端 Apollo/URQL 客户端默认走
graphql-ws协议，而graphql-go无法原生对接，得额外写适配层
如果你的业务明确需要订阅，不如直接换 gqlgen——它生成代码时就预留了 Subscribe 方法签名，底层也内置了 WebSocket handler。
gqlgen 生成的 resolver 怎么接入已有 HTTP 路由？
gqlgen 默认生成 server.NewDefaultServer，返回一个 http.Handler，但它内部用的是 net/http.ServeMux，和你项目里已有的 Gin/Echo/Chi 不兼容。强行挂载会导致中间件失效、路径冲突、甚至 panic。
- 正确做法：调用
handler.NewDefaultServer(...)得到一个*handler.Server，它实现了http.Handler接口，可直接作为子路由 handler 注册 - Gin 示例：
r.POST("/graphql", gin.WrapH(gqlHandler))，其中gqlHandler是*handler.Server - 注意：gqlgen 的
Playground是独立路由（如/playground），需单独注册，且默认只在 dev 环境开启
容易被忽略的是 gqlgen 对 context.Context 的处理：它会把请求上下文自动注入 resolver 的 ctx 参数，但中间件里加的 value（比如用户 ID）必须通过 graphql.WithContext 显式传递，否则 resolver 拿不到。
