如何将Prisma生成的类型用作函数参数类型？

优先选择复用Prisma生成的安全类型 #

不用直接传递查询到的实例，而是从实例中提取主键（比如id）来构造connect结构，完全符合Prisma的安全输入规范，同时能直接复用自动生成的类型，不用额外维护：

// 服务层：把查询到的实例转换为符合InviteCreateInput的结构
async function createInvite(role: Role, organisation: Organisation, inviteInfo: Omit<InviteCreateInput, 'role' | 'organisation'>) {
  const createPayload: InviteCreateInput = {
    ...inviteInfo,
    role: { connect: { id: role.id } },
    organisation: { connect: { id: organisation.id } }
  };
  return await inviteRepo.save(createPayload);
}

// 仓库层：直接接收InviteCreateInput类型参数
async function save(data: InviteCreateInput) {
  return await prisma.invite.create({ data });
}

自定义类型适配业务调用习惯 #

如果觉得每次手动构造connect太繁琐，可以自定义一个更贴合业务场景的输入类型，然后在仓库层做转换：

// 自定义类型：允许直接传入关联实例
type InviteCreateWithExistingRelations = Omit<InviteCreateInput, 'role' | 'organisation'> & {
  role: Role;
  organisation: Organisation;
};

// 仓库层：将自定义类型转换为Prisma要求的结构
async function save(data: InviteCreateWithExistingRelations) {
  const prismaData: InviteCreateInput = {
    ...data,
    role: { connect: { id: data.role.id } },
    organisation: { connect: { id: data.organisation.id } }
  };
  return await prisma.invite.create({ data: prismaData });
}

这种方式让服务层的调用更直观，但需要注意：当Prisma模型更新时，要同步调整自定义类型，避免出现类型不一致。

谨慎使用Unchecked类型 #

Prisma不推荐InviteUncheckedCreateInput的核心原因是它跳过了外键约束校验，可能导致数据库出现无效关联（比如传入不存在的关联ID）。如果你的业务逻辑已经100%确保了关联实例的合法性（比如服务层已经查询到有效实例），理论上可以用，但一旦业务逻辑变更，很容易引入数据不一致的风险，所以除非有特殊需求，不建议优先选这个方案。

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