GraphQL的fields不支持Promise？如何定义异步fields resolver

GraphQL 原生GraphQLObjectType的fields配置项仅支持同步返回字段配置，不支持异步Promise返回，以下是可落地的变通方案，按推荐优先级排序：

方案1：预加载异步资源后同步构建Schema（推荐） #

GraphQL的Schema设计上是服务启动阶段就完成构建的静态结构，你完全可以先把fields依赖的所有异步逻辑执行完，拿到最终的字段配置后，再同步初始化GraphQL类型，完全符合官方规范，无兼容性问题。
示例代码：

import {
  GraphQLString,
  GraphQLObjectType,
  GraphQLList,
  GraphQLSchema
} from 'graphql';

async function buildSchema() {
  // 此处放你原本要写在fields里的异步逻辑，比如拉取动态字段配置、等待依赖模块加载
  await new Promise(r => setTimeout(r, 100));
  const dynamicFields = await loadCustomFieldConfig(); // 自定义异步配置拉取逻辑

  const MessageType = new GraphQLObjectType({
    name: 'Message',
    // 异步逻辑已执行完成，此处直接同步返回字段配置即可
    fields: () => ({
      text: { type: GraphQLString },
      comments: { type: new GraphQLList(MessageType) },
      ...dynamicFields
    }),
  });

  // 组装完整可使用的Schema
  return new GraphQLSchema({
    query: new GraphQLObjectType({
      name: 'Query',
      fields: { message: { type: MessageType } }
    })
  });
}

// 服务启动时等待Schema构建完成，再启动HTTP服务
const appSchema = await buildSchema();
// 后续将appSchema传入你使用的GraphQL服务库（apollo-server、express-graphql等）即可

该方案优势：

• 完全兼容所有GraphQL生态工具，无黑魔法，稳定性高
• 递归自引用类型（比如示例中Message嵌套自身的场景）可正常工作，无需额外处理
• 避免运行时动态修改Schema带来的类型不一致、性能损耗、内存泄漏问题

方案2：将异步逻辑迁移到字段resolve函数 #

如果你写异步fields的初衷是在字段查询时执行异步数据获取，根本不需要让fields支持异步。GraphQL原生支持字段的resolve函数返回Promise，所有业务层面的异步逻辑（查库、调接口、延迟计算等）都应该放在resolve中执行，这是GraphQL的标准设计约定。
示例代码：

import {
  GraphQLString,
  GraphQLObjectType,
  GraphQLList
} from 'graphql';

const MessageType = new GraphQLObjectType({
  name: 'Message',
  fields: () => ({
    text: { type: GraphQLString },
    comments: {
      type: new GraphQLList(MessageType),
      // 异步逻辑直接写在resolve中，原生支持
      resolve: async (parent) => {
        await new Promise(r => setTimeout(r, 100));
        // 此处可执行任意异步操作：查数据库、调用第三方接口、权限校验等
        return parent.comments;
      }
    }
  })
});

注意事项 #

1. 你提供的示例代码存在几处语法/用法错误：
   • 延迟逻辑写法错误：Promise.resolve(r => setTimeout(r, 100))不会等待定时器执行，正确写法为new Promise(r => setTimeout(r, 100))
   • 未导入GraphQLList类型
   • comments字段配置未包裹{ type: ... }结构，不符合字段配置规范
   • return语句末尾多写了一个分号，存在语法错误
2. 不要尝试用deasync之类的同步阻塞库强行把异步逻辑转成同步传入fields，这类方案会导致服务性能骤降、内存异常，在Serverless、边缘计算环境下基本无法正常运行
3. 如果是多租户场景需要不同租户对应不同字段配置，可以在租户配置变更时重新生成新的Schema实例替换旧实例，不要在单个Schema的fields函数中做动态异步逻辑

内容的提问来源于stack exchange，提问作者teteyi3241