NestJS微服务：端点DTO验证的最佳实践探讨

针对你提出的API网关与微服务的验证分工疑问，以及自定义验证（如邮箱唯一性）的实现问题，直接给出落地的最佳实践方案：

一、明确两类验证的分工边界 #

验证可以分为基础格式验证和业务规则验证，两者的放置位置完全不同：

• 基础格式验证（如邮箱格式、字段非空、数据类型校验）：可以在API网关做前置拦截，目的是快速过滤明显无效的请求，减轻下游微服务的压力。但注意：微服务自身必须重复做同样的基础验证——因为网关可能被绕过（比如内部服务直接调用微服务、网关故障时的临时路由），微服务要保证自身数据输入的合法性，不能依赖网关。
• 业务规则验证（如邮箱唯一性、密码符合业务复杂度规则、用户权限校验）：必须放在微服务内部。这类验证需要访问业务数据（如查询数据库）、耦合业务逻辑，网关的职责是路由、鉴权、流量管控，不应该绑定业务细节，否则会导致网关变成"上帝服务"，难以维护和扩展。

二、自定义业务验证（邮箱唯一性）的具体实现 #

以你的用户微服务为例，正确的实现步骤如下：

1. 微服务DTO中添加完整验证规则 #

修改user-microservice的CreateUserDto，同时保留基础格式验证和添加自定义业务验证：

// user-microservice/src/dto/create-user.dto.ts
import { IsNotEmpty, IsEmail, Validate } from 'class-validator';
import { UniqueEmailValidator } from '../validators/unique-email.validator';

export class CreateUserDto {
  @IsNotEmpty({ message: '邮箱不能为空' })
  @IsEmail({}, { message: '邮箱格式不正确' })
  @Validate(UniqueEmailValidator, { message: '该邮箱已被注册' })
  email: string;

  @IsNotEmpty({ message: '密码不能为空' })
  @IsString({ message: '密码必须为字符串类型' })
  password: string;
}

2. 实现自定义验证器 #

创建自定义验证器类，注入业务服务来查询数据库验证邮箱唯一性：

// user-microservice/src/validators/unique-email.validator.ts
import { ValidatorConstraint, ValidatorConstraintInterface, ValidationArguments } from 'class-validator';
import { Injectable } from '@nestjs/common';
import { UserService } from '../user.service';

@ValidatorConstraint({ name: 'uniqueEmail', async: true })
@Injectable()
export class UniqueEmailValidator implements ValidatorConstraintInterface {
  constructor(private readonly userService: UserService) {}

  // 验证逻辑：查询数据库是否存在该邮箱
  async validate(email: string, args: ValidationArguments) {
    const existingUser = await this.userService.findByEmail(email);
    return !existingUser; // 不存在则验证通过
  }

  // 验证失败时的提示信息
  defaultMessage(args: ValidationArguments) {
    return `邮箱 ${args.value} 已被注册`;
  }
}

3. 微服务启用验证管道 #

在微服务中全局注册ValidationPipe，确保所有入参都会经过验证：

// user-microservice/src/main.ts
import { NestFactory } from '@nestjs/core';
import { ValidationPipe } from '@nestjs/common';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.createMicroservice(AppModule, {
    // 你的微服务配置（如TCP/RMQ）
  });
  // 启用验证管道，自动验证DTO
  app.useGlobalPipes(new ValidationPipe({
    whitelist: true, // 过滤DTO中未定义的字段
    transform: true, // 自动将请求数据转换为DTO实例
  }));
  await app.listen();
}
bootstrap();

4. 网关侧的验证调整 #

网关只保留基础格式验证即可，移除任何业务相关的验证逻辑，避免耦合：

// api-gateway/src/dto/create-user.dto.ts
import { IsNotEmpty, IsEmail, IsString } from 'class-validator';

export class CreateUserDto {
  @IsNotEmpty()
  @IsEmail()
  email: string;

  @IsNotEmpty()
  @IsString()
  password: string;
}

三、额外优化：避免重复DTO定义 #

为了避免网关和微服务重复编写相同的基础验证规则，可以把基础DTO抽象成内部共享库（比如发布为私有NPM包、或者用NestJS的共享模块），网关和微服务都引用这个库，只在微服务的DTO中添加业务相关的验证装饰器，减少重复代码。

内容的提问来源于stack exchange，提问作者Young Al Capone