选gqlgen。它通过schema-first和代码生成实现强类型安全，避免拼写错误与类型不一致；graphql-go纯运行时解析，错误延迟暴露、调试成本高；微服务协作中，gqlgen的codegen机制保障接口契约可靠性。
GraphQL 服务端用 gqlgen 还是 graphql-go？
选 gqlgen。它生成强类型 Go 代码，配合 schema-first 开发流程，能天然规避字段拼写错误、类型不一致等问题；graphql-go 是纯运行时解析，字段名写错只会在请求时暴露，调试成本高。微服务场景下，schema 往往由多个团队协作维护，gqlgen 的 codegen 机制让接口契约更可靠。
实操建议：
- 用
gqlgen init初始化项目，生成graph/schema.graphql和graph/generated/generated.go - 修改
schema.graphql后必须重新运行go run github.com/99designs/gqlgen generate，否则 resolver 实现和生成代码会脱节 - resolver 接口定义在
graph/generated/generated.go中，实际实现写在graph/resolver.go，别直接改 generated 文件
如何把多个微服务的 GraphQL API 聚合成一个统一入口？
用 Apollo Federation 或 Graph Gateway（如 WunderGraph、GraphQL Mesh），但 Go 生态里最轻量可控的是 graphql-go/federation + 自定义 ResolveField。关键不是“拼接”，而是把下游服务当作数据源封装成 Resolver。
常见错误现象：context deadline exceeded 或字段返回 null 却无日志——通常是因为下游 HTTP 请求没设超时或没透传 context.Context。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 每个微服务暴露标准 GraphQL endpoint（如
http://user-svc/graphql），并在其 schema 中加@key(fields: "id")等 federation 指令 - 网关层用
graphql-go/graphql构建 server，用http.Client调用下游，务必用ctxhttp.Do(ctx, client, req)而非client.Do(req) - 避免在 resolver 里做多次串行 HTTP 请求；对关联字段（如
User.posts），优先用 batch-loader（如github.com/vektah/dataloaden）合并请求
resolver 中怎么安全调用其他微服务？
不能裸写 http.Get，必须处理重试、熔断、超时、错误分类。Go 原生 net/http 不提供这些能力，得靠中间件或客户端封装。
使用场景：用户服务查订单时需调订单服务，但订单服务临时不可用，应降级返回空数组而非整个查询失败。
实操建议：
- 用
github.com/sony/gobreaker包包装下游调用，状态码5xx触发熔断，404不计入失败计数 - 超时时间按下游 SLA 设：比如订单服务 P99 是 200ms，这里设
context.WithTimeout(ctx, 300ms)，留出缓冲 - 错误要分类处理：
errors.Is(err, context.DeadlineExceeded)返回graphql.Error并标记extensions字段，便于前端区分网络错误与业务错误
为什么 GraphQL 查询嵌套过深会导致性能崩塌？
不是 GraphQL 本身的问题，而是 resolver 实现没控制 N+1 查询或没做懒加载。比如查 10 个用户，每个用户调一次 GetPostsByUserID，就发了 10 次 DB 查询。
性能影响：单次查询延迟从 50ms 涨到 800ms，QPS 直接掉 80%。
实操建议：
- 所有涉及集合关联的 resolver（如
User.posts），必须用dataloaden生成 loader，禁止在 resolver 内直接调 DB 或 HTTP - 在
schema.graphql中用@deprecated标记已知低效字段，同时监控query.depth，超过 5 层拒绝执行 - 对高频字段（如
User.avatarUrl），预计算并缓存在 Redis，resolver 优先查缓存，未命中再回源
真正难的不是写 resolver，是让每个 resolver 都清楚自己处在调用链哪一层、下游能扛住多少并发、超时后该返回什么——这些细节不落地，再好的框架也救不了查询性能。
