NestJS 中使用 DTO 验证 JSONB 字段时的常见错误与正确实践

在 nestjs + postgresql 项目中，对 `jsonb` 字段使用 `@isjson()` 装饰器会导致 400 错误，因其要求输入为 json 字符串而非 javascript 对象；实际开发中通常无需该验证，orm（如 typeorm）会自动序列化对象并安全存入 `jsonb` 列。

当你在 NestJS 应用中使用 PostgreSQL 的 jsonb 类型存储结构化数据（如消息列表、配置对象等），常会误以为需用 class-validator 的 @IsJSON() 装饰器来校验字段。但这是一个典型误解：@IsJSON() 仅验证输入是否为合法的 JSON 格式字符串（例如 ‘{“key”:”value”}’），而非 JavaScript 对象字面量（例如 { key: “value” }）。

你的 postman 请求体：

{   "content": {     "messages": ["testing", "testing", "123"],     "detail": "some detail"   } }

发送的是标准 JSON 对象——这在 http 请求中完全合法，且 NestJS 的 ValidationPipe 会将其解析为 JavaScript 对象（即 IContent 实例）。此时若 DTO 中声明：

@IsJSON() content: IContent;

验证器会尝试将该对象（非字符串）传入 JSON.parse()，必然抛出 SyntaxError，最终触发 “content must be a json String” 错误。

✅ 正确做法是：移除 @IsJSON()，改用语义化验证装饰器组合，确保对象结构符合预期，同时信任 TypeORM 对 jsonb 的自动序列化能力：

// dto/create-item.dto.ts import { IsNotEmpty, ValidateNested, IsArray, IsString } from 'class-validator'; import { Type } from 'class-transformer';  export class ContentDto {   @IsArray()   @IsString({ each: true })   messages: string[];    @IsString()   @IsNotEmpty()   detail: string; }  export class CreateItemDto {   @ValidateNested()   @Type(() => ContentDto)   content: ContentDto; }

对应实体定义保持简洁：

// entities/item.entity.ts import { Entity, column, PrimaryGeneratedColumn } from 'typeorm';  @Entity() export class Item {   @PrimaryGeneratedColumn('uuid')   id: string;    @Column('jsonb', { nullable: false, default: () => '{}' })   content: IContent; // 接口仅作类型提示，运行时不参与序列化 }

? 注意事项：jsonb 列在 TypeORM 中接收 JavaScript 对象后，会自动调用 JSON.stringify() 存入数据库；读取时自动 JSON.parse() 还原为对象——你无需手动处理序列化。若需深度校验嵌套结构（如 messages 必须为非空字符串数组），应使用 @ValidateNested + @Type（来自 class-transformer）配合具体字段装饰器，而非 @IsJSON()。default: {} 在 @Column 中不被 TypeORM 支持为对象字面量；应改用 default: () => ‘{}’ 或迁移时通过 DEFAULT ‘{}’::jsonb 显式定义。前端/Postman 发送对象即可，切勿手动 JSON.stringify() 再传入（否则后端收到的是字符串，jsonb 列将存储双重转义的字符串，丧失查询能力）。

总结：@IsJSON() 是为校验“字符串形式的 JSON”而生（如 API 接收 raw string payload），而在标准 REST 场景下，客户端发送 JSON 对象 → NestJS 解析为 JS 对象 → TypeORM 自动序列化为 jsonb，这条链路天然健壮。聚焦业务逻辑验证，而非强行套用不匹配的校验规则，才能写出清晰、可维护的 NestJS 数据层代码。