graphql服务启动panic的主因是resolver未注册，需检查方法签名、指针接收者及gqlgen生成代码是否引用正确实现。
GraphQL 服务启动就 panic：没注册 resolver
用 graphql-go/graphql 或 99designs/gqlgen 启动服务时直接崩溃，常见错误是 panic: field "xxx" not defined on type "yyy"。这不是 schema 写错了，而是 resolver 函数没挂到对应字段上。
实操建议：
- 检查
Resolver结构体是否实现了所有 schema 中定义的字段方法（注意大小写、参数签名必须完全匹配） - 用
gqlgen generate后务必看生成的generated.go，确认它引用的是你写的 resolver 实例，不是空结构体 - 如果手写 resolver，别漏掉指针接收者 ——
func (r *queryResolver) User(...) {...}和func (r queryResolver) User(...) {...}在接口实现上不等价 -
gqlgen默认要求 resolver 方法返回interface{}或具体类型 +error，返回(T, error)是对的，但返回T单值会编译失败
Query 参数解析失败：input object 和 scalar 混用
前端传了 { filter: { name: "a" } }，后端 resolver 却收不到 filter，或者报 cannot unmarshal string into Go struct。问题常出在 Go struct tag 和 GraphQL input type 的映射关系上。
实操建议：
- GraphQL input object 对应 Go struct，字段名默认按首字母大写自动映射，但必须加
json:"fieldName"tag 才能被gqlgen正确解码 - 别在 input struct 里嵌套自定义 scalar（比如
DateTime），除非你已注册该 scalar 的Marshal/Unmarshal函数 - 如果用了
map[string]interface{}接参数，gqlgen会拒绝 —— 它只认强类型 struct - 前端传
null给非 nullable 字段时，Go 端收到的是零值（如""或0），不是nil；需要可空字段，用指针类型：*string
并发下 context 被提前 cancel：resolver 没传透 context
HTTP 请求还没返回，日志里就出现 context canceled，数据库查询或下游 HTTP 调用中途退出。根本原因是 resolver 函数里新建了 context，或忘了把入参 ctx context.Context 传给子调用。
实操建议：
- 每个 resolver 方法签名第一参数必须是
ctx context.Context，且所有子调用（DB 查询、HTTP client、channel 操作）都得显式传这个ctx - 别在 resolver 里用
context.Background()或context.WithTimeout(context.Background(), ...)—— 这会断掉父请求的超时和取消链 - 如果用了
gqlgen，它的FieldContext里有ctx字段，别只取ec.Context()就完事，要确保整个调用树都用同一个ctx - 中间件（如 auth、logging）注入的 value，也要通过
ctx.Value()取，而不是靠全局变量或闭包捕获
schema 更新后前端报错：gqlgen generate 没跑全
改了 schema.graphql，加了新字段，前端 query 却提示 Cannot query field "xxx" on type "yyy"。不是前端缓存问题，是 Go 侧代码没同步更新。
实操建议：
- 每次改 schema 后，必须运行
go run github.com/99designs/gqlgen generate，不能只改resolver.go - 生成的
models_gen.go和generated.go是强依赖，删掉任一文件都会导致编译失败或 runtime panic - 如果用了
model映射（如type User @model(model: "github.com/xxx/user")），确保目标 struct 字段 tag 和 schema 字段名一致，否则生成代码会跳过该字段 -
gqlgen.yml里的autobind路径必须包含你 resolver 方法所在包，否则生成器找不到实现，会 fallback 到 panic stub
最麻烦的其实是 resolver 方法签名和 schema 类型的隐式耦合 —— 看似只是加个字段，背后可能牵扯 context 传递、error 处理路径、nullable 控制，这些地方一漏，问题就藏得深。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
