resolver 返回空是因为 gqlgen 不自动转发请求，需手动调用下游接口并映射结果；必须显式发起 http/grpc 调用、透传 context、用 batching/dataloader 控制并发、错误须转为 gqlerror 并设 extensions，非关键字段应返回零值+error 实现降级。
用 gqlgen 搭建 BFF 层时，为什么 resolver 总是返回空？
因为默认 resolver 不会自动转发字段请求到下游服务，你得手动写逻辑去调用 HTTP/gRPC 接口并映射结果。gqlgen 只负责 GraphQL 协议层，不内置数据源聚合能力。
- 常见错误现象：
data字段返回null，但 network 面板里没看到任何下游请求发出 - 必须在
Resolver方法里显式发起调用，比如用http.Client请求用户服务的/api/v1/user/{id} - 注意 context 传递：下游调用要带上原始请求的
context.Context，否则超时和取消无法透传 - 别直接在 resolver 里做并发控制（如
sync.WaitGroup），优先用gqlgen内置的Batching或DataLoader模式
GraphQL 查询嵌套深了，Go 服务 CPU 突增甚至 OOM 怎么办？
深层嵌套触发大量并发下游请求，又没限流/熔断，Go runtime 调度压力陡增，goroutine 泛滥是主因。
- 典型场景：一个
query { order(id: "1") { items { product { inventory { stock } } } } }可能拉起 10+ 并发 HTTP 请求 - 用
semaphore.NewWeighted(5)包裹下游调用，硬性限制并发数，比靠 goroutine 数量判断更可靠 -
gqlgen的FieldMiddleware是插桩好位置，可统一加熔断（如sony/gobreaker）和超时 - 避免在 resolver 中解析 JSON 响应体两次——下游返回结构体后，直接映射到 GraphQL 对象字段，别先
json.Unmarshal成map[string]interface{}
微服务返回的错误码（如 404、503）怎么透传给前端？
GraphQL 规范要求错误走 errors 数组，不是 HTTP 状态码；直接返回 503 会让整个 query 失败，连带其他字段也拿不到。
- 下游返回 404 时，不要 panic 或 return nil，而应构造
gqlerror.Error并设置Extensions字段，比如map[string]interface{}{"code": "USER_NOT_FOUND"} - HTTP 状态码只用于 BFF 自身健康判断（如反向代理失败），业务错误一律收进
errors，由前端按extensions.code分支处理 - 注意：如果多个 resolver 并发出错，
gqlgen默认把它们全塞进同一个errors数组，前端需按path字段定位具体哪个字段失败
如何让 Go BFF 支持部分字段降级，而不是整条 query 失败？
关键在 resolver 返回值设计 —— 允许字段返回零值 + 错误，而不是让 error 导致父级字段失效。
立即学习“go语言免费学习笔记（深入）”；
- resolver 函数签名必须是
func() (T, error)形式，且T是非指针类型（如string而非*string），这样即使 error != nil，T仍可返回默认值（如空字符串、0、false） - 对非关键字段（如用户头像 URL），下游超时就返回空字符串 +
gqlerror.Errorf("avatar service timeout")，不影响用户名等主干字段 - 别依赖中间件统一 recover panic 来实现降级 —— panic 是异常路径，掩盖了本该主动处理的业务容错逻辑
