GraphQL权限控制实现咨询：普通用户与管理员数据隔离

不用特意创建两个根查询（users和usersForAdmins），这种做法会让你的Schema变得冗余且难以维护。GraphQL的权限控制最佳实践是字段级别的权限校验，或者结合自定义指令来简化逻辑，下面我详细给你拆解：

1. 字段级别直接做权限校验（最直观的方式） #

首先定义一个统一的User类型，包含所有可能的字段，然后在字段的解析器中根据当前用户的角色判断是否允许访问。

第一步：定义Schema #

type User {
  id: ID!
  username: String! # 普通用户和管理员都能看
  email: String! # 仅管理员可见
  createdAt: String! # 公共字段
  lastLogin: String! # 仅管理员可见
}

type Query {
  users: [User!]! # 所有用户都能调用，但返回的字段会受权限限制
  user(id: ID!): User
}

第二步：在解析器中实现权限校验 #

核心是利用GraphQL的**上下文（Context）**传递当前登录用户的信息（比如角色、ID等），然后在字段解析时判断权限：

// 以Node.js + Apollo Server为例
const resolvers = {
  User: {
    // 校验email字段的访问权限
    email: (parent, args, context) => {
      // context.user是从请求头解析出的当前登录用户信息
      if (context.user?.role !== 'ADMIN') {
        throw new Error('权限不足：仅管理员可查看用户邮箱');
      }
      return parent.email;
    },
    // 校验lastLogin字段的访问权限
    lastLogin: (parent, args, context) => {
      if (context.user?.role !== 'ADMIN') {
        throw new Error('权限不足：仅管理员可查看用户登录时间');
      }
      return parent.lastLogin;
    }
  },
  Query: {
    users: (parent, args, context) => {
      // 这里可以先校验是否允许调用该查询（比如普通用户也能查看用户列表）
      return db.getAllUsers(); // 返回所有用户的完整数据，但字段会被权限过滤
    },
    user: (parent, { id }, context) => {
      return db.getUserById(id);
    }
  }
};

这种方式的好处是：

• 只用维护一套User类型和查询，避免冗余
• 权限控制精准到单个字段，灵活度高
• 普通用户请求管理员字段时，会收到明确的错误提示（或你可以返回null，根据业务需求调整）

2. 用自定义指令简化权限校验（更优雅的方式） #

如果有很多字段需要权限控制，重复写校验逻辑会很繁琐，这时可以自定义一个@auth指令，统一处理权限判断。

第一步：定义指令和Schema #

# 定义权限角色枚举
enum Role {
  USER
  ADMIN
}

# 自定义权限指令，标记需要权限的字段
directive @auth(requires: Role = USER) on FIELD_DEFINITION

type User {
  id: ID!
  username: String!
  email: String! @auth(requires: ADMIN) # 标记需要管理员权限
  createdAt: String!
  lastLogin: String! @auth(requires: ADMIN) # 标记需要管理员权限
}

type Query {
  users: [User!]!
  user(id: ID!): User
}

第二步：实现指令逻辑 #

以Apollo Server为例，你可以创建一个指令类来处理权限校验：

const { SchemaDirectiveVisitor } = require('apollo-server');
const { defaultFieldResolver } = require('graphql');

class AuthDirective extends SchemaDirectiveVisitor {
  visitFieldDefinition(field) {
    const { resolve = defaultFieldResolver } = field;
    const { requires } = this.args;

    field.resolve = async function(...args) {
      const [, , context] = args;
      const userRole = context.user?.role;

      if (!userRole || userRole !== requires) {
        throw new Error(`权限不足：需要${requires}角色`);
      }

      return resolve.apply(this, args);
    };
  }
}

然后在创建Apollo Server时注册这个指令：

const server = new ApolloServer({
  typeDefs,
  resolvers,
  schemaDirectives: {
    auth: AuthDirective
  },
  context: ({ req }) => {
    // 从请求头解析用户信息，比如JWT token
    const user = parseUserFromToken(req.headers.authorization);
    return { user };
  }
});

这种方式的好处是权限逻辑复用性强，Schema更清晰，一眼就能看出哪些字段需要特殊权限。

为什么不推荐创建两个根查询？ #

创建users和usersForAdmins这种分开的查询会带来几个问题：

• 冗余：需要维护两套几乎一样的类型（比如User和AdminUser），增加代码量和维护成本
• 不灵活：如果后续需要新增角色（比如Moderator），又要新增对应的查询和类型
• 不符合GraphQL的设计理念：GraphQL强调按需获取数据，字段级控制才是更自然的权限管理方式

额外注意事项 #

• 上下文（Context）是核心：不管用哪种方式，都要确保在Context中正确传递当前用户的身份信息（从请求头、Cookie等地方获取并解析）
• 错误处理：根据业务需求决定，是抛出错误还是返回null，但建议返回明确的错误信息，方便前端处理
• 数据层面的保护：即使做了GraphQL层面的权限控制，后端数据库查询也最好做额外的过滤，避免敏感数据被意外返回（比如管理员字段即使解析器报错，也不要从数据库查询出来）

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