graphql中需通过golang层拦截错误实现局部成功：用defer+recover捕获panic，将错误存入线程安全的fielderrors容器，再由自定义responseformatter注入errors并置字段为null。
GraphQL里怎么让部分字段失败不影响整体响应
GraphQL本身不支持“局部成功”——默认只要一个resolver panic 或返回 error，整个请求就退化为 errors 数组 + 空 data。但业务上常需要：用户资料查不到，订单列表仍要返回。得靠 Golang 层主动拦截错误、降级处理。
关键不是改 GraphQL 规范，而是控制 resolver 的 error 传播路径：
- 所有可能出错的字段 resolver 必须用
defer+recover()捕获 panic，再转成可识别的错误类型 - 在 resolver 内部不直接 return
err，而是把 error 存进 context（比如用graphql.WithResponseContext注入的 map） - 用
graphql.ResponseFormatter自定义响应组装逻辑：遍历response.Data字段时，对每个字段检查 context 中对应的 error，有则填入response.Errors并设该字段为null
为什么不能只靠 gqlgen 的 CustomError 配置
gqlgen 的 CustomError 只能统一格式化 error 输出，无法阻止 error 向上传播导致整条 data 被清空。它发生在错误已生成之后，属于“事后美化”，不是“事中隔离”。
真实限制来自 graphql-go/graphql 或 gqlgen 默认执行器：一旦某个 resolve 返回非 nil error，执行器就会标记该字段不可用，并跳过子字段解析——你根本没机会让它继续跑订单列表。
立即学习“go语言免费学习笔记（深入）”；
所以必须在 resolver 执行阶段就切断错误冒泡：
- 不要在 resolver 函数签名里写
error返回值（gqlgen 自动生成的 resolver 接口允许这么做，但会触发默认失败逻辑） - 改用
interface{}+ 显式 error 处理，例如：return user, nil正常；return nil, fmt.Errorf("user not found")就不行，得改成return nil, nil并记日志+存 error 到 context - 注意
context.Context是 per-request 的，别用全局变量或共享 map，否则并发下会串数据
Golang context 传 error 的安全写法
GraphQL resolver 是并发调用的，多个字段 resolver 可能同时往同一个 context 写 error。不能直接用 context.WithValue 塞 map，因为它是只读的。得用 sync.Map 或带锁结构体封装。
推荐做法是提前在入口（比如 HTTP handler）创建一个线程安全的 error 容器，注入到 context：
type FieldErrors struct {
m sync.Map
}
func (fe *FieldErrors) Set(fieldPath string, err error) {
fe.m.Store(fieldPath, err)
}
func (fe *FieldErrors) Get(fieldPath string) (error, bool) {
if v, ok := fe.m.Load(fieldPath); ok {
return v.(error), true
}
return nil, false
}
然后在每个 resolver 里从 context 取出 *FieldErrors 实例调用 Set。这样既避免竞争，又能让 ResponseFormatter 按字段路径精准匹配错误。
容易被忽略的性能与兼容性点
局部成功听着好，但代价明显：错误不再中断执行，意味着所有字段 resolver 都会跑完，哪怕前面已经出错了。CPU 和 DB 查询量可能翻倍。
还要小心这些坑：
- 下游服务超时设置必须比 GraphQL 总超时短，否则单个慢 resolver 会拖垮整条请求
- 如果用了
dataloader（比如github.com/vektah/dataloaden），它的 batch 机制依赖 resolver 同步完成，局部成功下若某次 batch 请求失败但没正确标记，会导致后续字段拿到脏数据 - 前端 GraphQL 客户端（如 Apollo）默认把任何
errors当作请求失败，需手动检查data是否非空，否则页面直接白屏
真正难的不是实现局部成功，是怎么定义“哪些字段值得保、哪些该直接熔断”。这得看业务 SLA，不是加几行代码就能决定的。
