来自规范：
GraphQL 对象类型 (ObjectTypeDefinition)... 不适合重用 [作为输入]，因为对象类型可以包含定义参数的字段或包含对接口和联合的引用，这两者都不适合用作一个输入参数。因此，输入对象在系统中具有单独的类型。
这是“官方原因”，但有几个实际原因可以说明为什么不能将对象类型用作输入对象类型或将对象类型用作输入对象类型：
功能
对象类型和输入对象类型都具有字段，但是这些字段具有不同的属性，这些属性反映了架构如何使用这些类型。您的架构可能会为对象类型的字段定义参数和某种解析器函数，但这些属性在输入上下文中没有意义（即您不能解析输入对象的字段 -它已经有一个明确的值）。同样，只能为输入对象类型字段提供默认值，不能为对象类型字段提供默认值。
换句话说，这看起来像是重复：
type Student {
name: String
grade: Grade
}
input StudentInput {
name: String
grade: Grade
}
但是添加特定于对象类型或输入对象类型的功能可以清楚地表明它们的行为不同：
type Student {
name(preferred: Boolean): String
grade: Grade
}
input StudentInput {
name: String
grade: Grade = F
}
类型系统限制
GraphQL 中的类型分为输出类型和输入类型。
输出类型是可以作为 GraphQL 服务生成的响应的一部分返回的类型。输入类型是字段或指令参数的有效输入类型。
这两组之间存在重叠（即标量、枚举、列表和非空值）。但是，抽象类型如联合和接口在输入上下文中没有意义，不能用作输入。分离对象类型和输入对象类型可以确保在需要输入类型的地方永远不会使用抽象类型。
架构设计
在您的架构中表示实体时，某些实体可能确实会在其各自的输入和输出类型之间“共享字段”：
type Student {
firstName: String
lastName: String
grade: Grade
}
input StudentInput {
firstName: String
lastName: String
grade: Grade
}
但是，对象类型可以（实际上经常这样做）为非常复杂的数据结构建模：
type Student {
fullName: String!
classes: [Class!]!
address: Address!
emergencyContact: Contact
# etc
}
虽然这些结构可能转换为适当的输入（我们创建了一个学生，所以我们也传递了一个代表他们地址的对象），但通常它们不会——也就是说，也许我们需要指定学生的类 ID 和部分 ID 的类，而不是对象。同样，我们可能有想要返回但不想改变的字段，反之亦然（例如 password 字段）。
此外，即使对于相对简单的实体，我们也经常对对象类型及其“对应”输入对象之间的可空性有不同的要求。通常我们希望保证一个字段也将在响应中返回，但我们不想在我们的输入中设置相同的字段。例如，
type Student {
firstName: String!
lastName: String!
}
input StudentInput {
firstName: String
lastName: String
}
最后，在许多模式中，给定实体的对象类型和输入对象类型之间通常没有一对一的映射。一种常见的模式是针对不同的操作使用单独的输入对象类型，以进一步微调模式级输入验证：
input CreateUserInput {
firstName: String!
lastName: String!
email: String!
password: String!
}
input UpdateUserInput {
email: String
password: String
}
所有这些示例都说明了一个重点——虽然输入对象类型有时可能反映对象类型，但由于业务需求，您不太可能在生产模式中看到这种情况。