GraphQL不支持标量联合类型？如何实现字段兼容Int或String

嘿，确实GraphQL的标量类型没法直接用|搞联合，我之前做项目的时候也踩过这个坑，给你几个实用的解决方案，你可以根据自己的场景选：

方案1：自定义标量类型（最规范的长期方案） #

自定义一个能同时处理Int和String的标量，比如叫IntOrString，然后实现它的序列化和解析逻辑。以Node.js的graphql库为例：

首先在schema里定义标量和输入类型：

scalar IntOrString

input QuickReply {
  content_type: String
  title: String
  payload: IntOrString
  image_url: String
}

然后在代码里实现这个标量的解析逻辑，处理序列化、客户端变量解析和查询字面量解析：

const { GraphQLScalarType, Kind } = require('graphql');

const IntOrStringScalar = new GraphQLScalarType({
  name: 'IntOrString',
  description: '支持Int或String类型的自定义标量',
  serialize(value) {
    // 把后端值转成前端可接收的格式
    if (typeof value === 'number' || typeof value === 'string') {
      return value;
    }
    throw new Error('IntOrString只能序列化Int或String类型的值');
  },
  parseValue(value) {
    // 解析客户端传来的变量值
    if (typeof value === 'number' || typeof value === 'string') {
      return value;
    }
    throw new Error('IntOrString只能解析Int或String类型的变量');
  },
  parseLiteral(ast) {
    // 解析GraphQL查询中的字面量
    if (ast.kind === Kind.INT) {
      return parseInt(ast.value, 10);
    } else if (ast.kind === Kind.STRING) {
      return ast.value;
    }
    throw new Error('IntOrString的字面量必须是Int或String类型');
  },
});

最后把这个标量加到你的GraphQL schema的resolvers配置里就行。这个方案的优势是类型检查严格，前后端对字段类型的认知一致，适合需要长期维护的项目。

方案2：拆分字段+类型标记（灵活的业务适配方案） #

因为GraphQL的输入类型不支持联合类型，我们可以把payload拆成两个可选字段，再加一个类型标记字段来区分传入的是Int还是String：

input QuickReply {
  content_type: String
  title: String
  payload_type: String! # 可选值为"INT"或"STRING"
  payload_int: Int
  payload_string: String
  image_url: String
}

然后在后端业务逻辑里，根据payload_type来读取对应的字段，并做必要的校验：

// 示例后端处理逻辑
function handleQuickReply(input) {
  let payload;
  switch (input.payload_type) {
    case 'INT':
      payload = input.payload_int;
      if (payload === undefined) {
        throw new Error('当payload_type为INT时，必须传入payload_int');
      }
      break;
    case 'STRING':
      payload = input.payload_string;
      if (payload === undefined) {
        throw new Error('当payload_type为STRING时，必须传入payload_string');
      }
      break;
    default:
      throw new Error('无效的payload_type，仅支持INT或STRING');
  }
  // 后续业务处理逻辑
}

这个方案不需要自定义标量，业务逻辑的灵活性更高，还能方便地添加额外的校验规则，适合业务场景多变的项目。

方案3：统一用String类型，后端做转换（最简单的临时方案） #

如果赶进度或者业务场景简单，也可以直接把payload定义成String类型，前端传值时把数字转成字符串，后端接收后再判断是否需要转换为Int：

input QuickReply {
  content_type: String
  title: String
  payload: String!
  image_url: String
}

后端处理逻辑示例：

function handleQuickReply(input) {
  let payload = input.payload;
  // 尝试将字符串转换为Int，如果转换成功则使用数字类型
  const numPayload = parseInt(payload, 10);
  if (!isNaN(numPayload) && String(numPayload) === payload) {
    payload = numPayload;
  }
  // 后续业务处理逻辑
}

这个方案最省事，但缺点是类型不够明确，前端可能需要额外注意传值格式，而且如果存在纯数字的字符串业务需求，需要额外处理边界情况，适合快速迭代的临时场景。

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