NestJS/Prisma中如何基于用户角色返回差异化API响应字段

核心思路是把字段权限控制和业务逻辑完全解耦，不要在控制器/服务里写硬编码的角色判断分支，保证单套业务逻辑复用，字段裁剪逻辑统一维护，和你已有的RBAC角色守卫无缝衔接。

具体实现路径 #

1. 优先用白名单维护各角色可访问字段 #

不要用黑名单模式——新增字段时黑名单会默认把新字段暴露给所有角色，很容易出数据泄露问题；白名单模式下新增字段默认对非管理员角色不可见，安全边界更清晰。
直接在对应业务模块下维护字段映射即可，比如用户模块：

// src/user/constants/field-permission.constant.ts
export enum UserRole {
  ADMIN = 'ADMIN',
  USER = 'USER'
}

// 不同接口可以维护独立的白名单映射，不用和实体强绑定
export const USER_DETAIL_FIELD_WHITELIST: Record<UserRole, string[]> = {
  [UserRole.ADMIN]: ['id', 'username', 'email', 'phone', 'passwordHash', 'status', 'createdAt', 'updatedAt'],
  [UserRole.USER]: ['id', 'username', 'avatar', 'createdAt']
}

2. 复用现有RBAC守卫的上下文数据 #

你已经实现了角色守卫，只需要确认守卫正常把当前登录用户的信息挂载到request.user上、且包含role字段即可，不需要额外改造现有权限判断逻辑。

3. 用拦截器统一做返回值字段裁剪 #

写一个可复用的全局/模块级拦截器，搭配方法装饰器绑定对应白名单，不需要改动原有业务逻辑，就能自动完成返回值裁剪：

// src/common/interceptors/field-serializer.interceptor.ts
import { Injectable, ExecutionContext, CallHandler, NestInterceptor, UseInterceptors } from '@nestjs/common';
import { map, Observable } from 'rxjs';
import { Reflector } from '@nestjs/core';

// 方法装饰器，用来给指定接口绑定对应的字段白名单
export const FieldPermission = (whitelistMap: Record<string, string[]>) =>
  Reflector.createDecorator<Record<string, string[]>>()(whitelistMap);

@Injectable()
export class FieldSerializerInterceptor implements NestInterceptor {
  constructor(private reflector: Reflector) {}

  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const whitelistMap = this.reflector.get(FieldPermission, context.getHandler());
    // 没有绑定白名单的接口直接放行，不影响现有业务
    if (!whitelistMap) return next.handle();

    const req = context.switchToHttp().getRequest();
    const currentRole = req.user?.role;
    // 未匹配到角色配置时默认返回空字段，兜底防止数据泄露
    const allowedFields = whitelistMap[currentRole] ?? [];

    return next.handle().pipe(
      map((data) => {
        // 单条实体序列化逻辑
        const serializeItem = (item: Record<string, any>) => {
          if (!item || typeof item !== 'object') return item;
          return Object.fromEntries(
            Object.entries(item).filter(([key]) => allowedFields.includes(key))
          )
        }

        // 自动适配分页返回结构：保留total、pageNum等公共字段，只裁剪列表数据
        if (Array.isArray(data?.list)) {
          return {
            ...data,
            list: data.list.map(serializeItem)
          }
        }
        return serializeItem(data);
      })
    )
  }
}

控制器里的使用非常简单，原有业务逻辑完全不用改：

// src/user/user.controller.ts
@UseInterceptors(FieldSerializerInterceptor)
@Get(':id')
@FieldPermission(USER_DETAIL_FIELD_WHITELIST)
async getUserDetail(@Param('id') id: number) {
  // 服务层代码不用加任何角色判断，正常查全量数据返回即可
  return this.userService.findById(id);
}

4. 性能优化：直接在Prisma层过滤查询字段 #

如果接口返回数据量大、敏感字段/大字段多，可以直接在Prisma查询阶段就只查角色允许的字段，避免查出来多余字段再裁剪，性能更好。
写个简单的参数装饰器拿当前请求的角色即可：

// src/common/decorators/current-role.decorator.ts
import { createParamDecorator, ExecutionContext } from '@nestjs/common';
export const CurrentRole = createParamDecorator(
  (_: unknown, ctx: ExecutionContext) => ctx.switchToHttp().getRequest().user?.role
)

服务层根据角色动态生成Prisma的select配置：

// src/user/user.service.ts
async findById(userId: number, role: UserRole) {
  const allowedFields = USER_DETAIL_FIELD_WHITELIST[role];
  return this.prisma.user.findUnique({
    where: { id: userId },
    select: Object.fromEntries(allowedFields.map(field => [field, true]))
  })
}

如果业务不复杂、性能要求不高，直接用拦截器裁剪即可，代码侵入性更低；如果对性能敏感，就选Prisma层过滤的方案。

避坑说明 #

• 不推荐用ClassSerializerInterceptor的groups特性做角色字段控制：配置分散在各个DTO类里，角色多、接口多了之后很难统一维护，也没法灵活适配同一个实体在不同接口下的字段权限差异。
• 不要把字段控制逻辑写在守卫里：守卫的职责是判断接口访问权限，处理返回值属于拦截器的职责，分层混乱会导致后续维护成本陡增。
• 不要在控制器方法里写if (role === 'ADMIN') return ... else return ...这类分支：接口数量多了之后会出现大量重复逻辑，改一个字段要同步改N处分支，很容易出bug。

内容的提问来源于stack exchange，提问作者Mohamed Al Ali