NestJS中让CreateUserDto继承PartialType(User)是否为最佳实践？

以下为提问中的代码示例：

user.entity.ts #

import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity()
export class User {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  firstName: string;

  @Column()
  lastName: string;

  @Column({ default: true })
  isActive: boolean;
}

create-user-dto.ts #

export class CreateUserDto extends PartialType(User) {}

结论：该写法不属于业界推荐的生产级项目最佳实践，仅适合快速原型、个人Demo等短期非维护场景使用，核心原因如下：

• 职责边界耦合
  Entity属于持久层模型，唯一职责是和数据库表做映射，承载数据持久化相关逻辑；DTO属于接口传输层模型，负责对外接口的入参/出参格式定义、校验规则配置，两者设计目标完全独立。直接继承会导致两层逻辑强耦合，后续修改数据库字段会直接影响对外接口的兼容性，违反单一职责原则。
• 存在安全风险
  示例中的CreateUserDto继承后所有字段均为可选状态，相当于把id（自增主键，不应该由调用方传入）、isActive（内置默认状态，不应该开放给外部修改）这类核心字段直接暴露给接口，恶意用户可以通过传入对应字段篡改核心数据，哪怕后续增加逻辑过滤，也会产生不必要的维护成本。
• 规则适配灵活度低
  Entity的装饰器都是数据库层的约束规则，而DTO通常需要搭配class-validator等工具配置接口层的校验规则，两类规则往往存在差异：比如某个字段在数据库层是必填项，但创建接口允许不传走默认值，直接继承的情况下无法灵活适配这类差异，强行在Entity中添加接口校验规则只会让代码逻辑越来越混乱。

如果是需要长期迭代维护的企业级项目，哪怕初期Entity和DTO的字段完全一致，也建议拆分定义，为后续业务迭代预留扩展空间。

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