如何在GraphQL Mutations中处理Union或Interface类型？

这个问题确实是GraphQL开发里的一个常见痛点——毕竟官方规范至今都不支持输入类型使用Union或Interface，处理这种带差异化属性的实体变更时，手写一堆重复的输入类型确实会越搞越繁琐。下面给你几个实用的解决方案，你可以根据自己的技术栈和需求来选：

方案一：通用输入类型+鉴别器字段 #

这是最常用的折中方案，核心思路是用一个通用的输入类型承载所有车型的字段，再加一个鉴别器字段（比如type）来标记当前是哪种车型，然后在业务层做属性合法性校验。

示例Schema：

# 定义车型枚举，方便后续扩展
enum VehicleType {
  CAR
  BOAT
}

# 各车型的属性输入类型
input CarPropertiesInput {
  wheelSize: Int!
  doors: Int!
}

input BoatPropertiesInput {
  length: Int!
}

# 通用的新增车辆输入类型
input AddVehicleInput {
  name: String!
  color: String!
  type: VehicleType! # 鉴别器字段
  carProperties: CarPropertiesInput # 对应CAR类型的属性，可选
  boatProperties: BoatPropertiesInput # 对应BOAT类型的属性，可选
}

# 同理可以定义通用的更新输入类型
input UpdateVehicleInput {
  id: ID!
  name: String!
  type: VehicleType!
  carProperties: CarPropertiesInput
  boatProperties: BoatPropertiesInput
}

type Mutation {
  addVehicle(input: AddVehicleInput!): Vehicle!
  updateVehicle(input: UpdateVehicleInput!): Vehicle!
}

关键逻辑 #

在Resolver里，根据type字段做校验：

• 如果type是CAR，则必须提供carProperties，且boatProperties必须为空
• 如果type是BOAT，则必须提供boatProperties，且carProperties必须为空

这种方案的优势是扩展性极强——新增车型只需要加枚举值和对应的属性输入类型，不用修改Mutation结构；缺点是输入类型本身无法做静态校验，必须依赖业务层的逻辑判断。

方案二：自定义Directive实现静态校验 #

如果你的服务端支持自定义Directive（比如Apollo Server、GraphQL.js），可以通过Directive把校验逻辑提前到Schema层面，避免业务层的重复判断。

示例Schema：

enum VehicleType {
  CAR
  BOAT
}

input CarPropertiesInput {
  wheelSize: Int!
  doors: Int!
}

input BoatPropertiesInput {
  length: Int!
}

# 自定义Directive，标记字段需要对应特定的车型
directive @requiresVehicleType(
  type: VehicleType!
  required: Boolean = true
) on INPUT_FIELD_DEFINITION

input AddVehicleInput {
  name: String!
  color: String!
  type: VehicleType!
  carProperties: CarPropertiesInput @requiresVehicleType(type: CAR)
  boatProperties: BoatPropertiesInput @requiresVehicleType(type: BOAT)
}

type Mutation {
  addVehicle(input: AddVehicleInput!): Vehicle!
}

关键逻辑 #

实现这个Directive的校验逻辑：当请求中的type是指定值时，对应的属性必须存在；如果type不是指定值，对应的属性必须为空。这样在请求到达业务层之前，就会被GraphQL服务端拦截并返回错误。

这种方案的优势是把校验逻辑统一管理，业务层可以更专注于业务逻辑；缺点是需要额外开发自定义Directive，有一定的学习和开发成本。

方案三：输入类型继承（依赖服务端支持） #

部分GraphQL服务端实现（比如Java的GraphQL SPQR、GraphQL.js的graphql-input-union扩展）支持输入类型的继承，你可以定义一个基础输入类型，然后让各车型的输入类型继承它，再在Mutation里定义对应字段。

示例Schema（以支持输入继承的服务端为例）：

# 基础输入类型，包含所有车型的共同字段
input BaseVehicleInput {
  name: String!
  color: String!
}

# 继承基础类型，添加车型专属属性
input CarVehicleInput extends BaseVehicleInput {
  carProperties: CarPropertiesInput!
}

input BoatVehicleInput extends BaseVehicleInput {
  boatProperties: BoatPropertiesInput!
}

type Mutation {
  addCar(input: CarVehicleInput!): Vehicle!
  addBoat(input: BoatVehicleInput!): Vehicle!
  updateCar(input: UpdateCarVehicleInput!): Vehicle!
  updateBoat(input: UpdateBoatVehicleInput!): Vehicle!
}

优化技巧 #

如果车型较多，可以用代码生成工具自动生成各车型的Mutation字段和Resolver，避免手动重复编写。

这种方案的优势是输入类型的校验是严格的，不用业务层额外处理；缺点是依赖服务端的非标准扩展，兼容性可能会有问题。

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