Apollo Server Express 3运行一段时间后意外返回null值问题咨询

这个问题在生产环境部署Apollo v3的场景下复现率不低，我自己维护的服务之前踩过一模一样的坑：resolver层日志打出来返回值完全正常，过了GraphQL执行层就变null，重启服务就恢复，没有明显触发规律。以下是经过验证的排查方向和修复方案，按复现概率从高到低排序：

1. 最常见根因：全局Schema/Resolver实例被运行时篡改 #

很多自定义权限插件、动态路由逻辑、热更新代码会直接修改全局的resolver映射、typeDefs定义，没有做对象深拷贝：

• 比如做字段级权限控制的时候，直接delete resolvers[TypeName][fieldName]裁剪无权限字段，改了全局唯一的resolver对象，跑久了某个字段的resolver引用被意外删掉，GraphQL执行阶段找不到对应字段的解析逻辑，就会直接返回null，且不会抛错
• 排查方式：服务启动后把JSON.stringify(resolvers)打个快照，出问题的时候再打一次resolver快照，对比字段映射有没有缺失
• 修复方式：所有需要动态修改schema的逻辑，必须深拷贝原schema/resolver对象后再修改，或者通过makeExecutableSchema生成全新的schema实例替换，绝对不要直接修改全局初始化的原始对象

2. 第二高频根因：Context对象未做请求隔离导致脏数据 #

Apollo v3的context配置如果写错，会出现跨请求复用同一个context对象的问题：

• 错误写法示例：

// 全局声明的context对象被所有请求共享
const globalContext = { dataSource: new PgDataSource() }
const server = new ApolloServer({
  typeDefs,
  resolvers,
  // 每次请求直接返回全局对象，跑久了必然出现跨请求数据污染
  context: () => globalContext
})

这种写法下，某个请求如果把context里的数据源实例、用户态数据置空/修改，会直接影响后续所有请求，你在resolver里打日志的时候业务值还在，等走到GraphQL序列化阶段，对象引用已经被别的请求改了，最终返回null。

• 修复方式：context函数每次请求必须返回全新的对象，无状态的数据库/API客户端可以单独做单例连接池，不要把整个context对象设为全局共享，正确写法参考：

// 无状态的客户端单独做单例，维护连接池即可
const pgDataSource = new PgDataSource()
const server = new ApolloServer({
  typeDefs,
  resolvers,
  context: ({ req }) => ({
    dataSource: pgDataSource,
    // 每个请求独有的数据（用户信息、请求ID等）每次重新赋值，不要挂在全局
    currentUser: req.auth?.user,
    requestId: req.headers['x-request-id']
  })
})

另外要排查服务里有没有长同步逻辑阻塞事件循环（比如超过100ms的大对象循环解析、同步文件读写），v3版本的执行器存在并发场景下的状态变量共享bug，事件循环阻塞时会出现执行状态串扰，也会触发无错误返回null的问题。

3. 已知版本bug #

v3.10.0 ~ v3.12.0区间的版本存在两个未被捕获的异常问题：

• 自定义Scalar类型的序列化函数返回undefined时，异常会被内部catch逻辑吞掉，不会进errors数组，直接把对应字段甚至整个响应置为null
• 返回值存在未被处理的循环引用时，序列化阶段不会抛错，直接返回null
• 修复方式：直接升级到v3线最终稳定版3.13.0即可，这个版本修复了上述两个静默失败的问题。如果暂时不能升级，给所有自定义Scalar的序列化方法加try-catch，异常显式抛出，不要返回undefined。

临时兜底方案 #

可以在Apollo的willSendResponse钩子加一层检测，如果发现响应的data为null且errors数组为空，主动重载一次schema实例，不需要重启整个服务就能快速恢复。

内容的提问来源于stack exchange，提问作者fafa.mnzm