TypeORM与TypeGraphQL中nullable参数配置位置及差异相关疑问

• @Field({ nullable: true })是TypeGraphQL的配置：作用于GraphQL Schema层，标记该字段在GraphQL查询返回、或者输入参数传递时允许为null。如果不配置这个参数，默认值是false，也就是字段非空：此时哪怕你返回的实际值是null，GraphQL运行时也会直接抛出校验错误，不会返回给客户端。
• @Column({ nullable: true })是TypeORM的配置：作用于数据库层，控制生成的数据库表对应字段是否允许存储NULL值。如果不配置默认是false，数据库会自带非空约束，当你尝试插入NULL值时会直接抛出数据库执行错误。
• 仅用TS的?标识可选类型完全无法满足需求：TS的类型校验只在编译期生效，编译为JS运行后所有类型信息都会被抹除，不管是GraphQL的运行时校验，还是数据库的非空约束，都不会读取TS的类型定义，所以仅写?没有任何运行时空值校验/放行的作用。

不需要完全强制一致，需要结合业务逻辑判断，但如果业务逻辑没有特殊要求，建议对齐避免不必要的错误：

• 如果某字段在数据库允许为NULL，且业务上创建/更新时允许不传或者传空值，那InputType中的对应字段也要设置nullable: true，否则GraphQL会直接拦截空值参数，导致mutation执行失败。
• 如果业务上某字段创建时必填，但后续可以被修改为NULL，那创建用的InputType可以设置nullable为false，Entity中设置nullable为true，这种特殊场景可以不对齐。

你遇到的偶发空值报错、mutation执行失败，核心是以下配置不匹配的问题：

1. Entity中clickId字段的@Field装饰器缺失nullable: true配置：

// 原错误配置
@Field(type => ID) // 这里默认nullable为false，GraphQL要求必须返回非空值
@Column({ nullable: true }) // 数据库允许为null
clickId?: string; 

修复为：

@Field(type => ID, { nullable: true })
@Column({ nullable: true })
clickId?: string; 

2. InputType中clickId字段配置和Entity不匹配：如果你的业务允许创建Click时不传clickId，就需要同步修改Input配置：

// 原错误配置
@Field(type => ID) // 必填，传空直接被GraphQL拦截
clickId: string; 

修复为：

@Field(type => ID, { nullable: true })
clickId?: string; 

3. InputType中url字段TS类型没有标记可选，建议和nullable配置对齐：

// 原配置
@Field({ nullable: true })
@MaxLength(256)  
url: string; 

修改为：

@Field({ nullable: true })
@MaxLength(256)  
url?: string; 

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