用 Composition API 和 Hook 做前端权限控制

这个版本够直白。hasPermission 负责单个权限，hasAnyPermission 处理一组权限里命中任意一个的情况。多数按钮显隐、菜单过滤场景，已经够用了。

在组件里用起来也很直接：

<template>
  <div>
    <button v-if="hasPermission('edit')">编辑</button>
    <button v-if="hasAnyPermission(['delete', 'admin'])">删除</button>
  </div>
</template>

<script>
import { usePermission } from '@/hooks/usePermission';

export default {
  setup() {
    const { hasPermission, hasAnyPermission } = usePermission();
    return { hasPermission, hasAnyPermission };
  },
};
</script>

再往前一步：useAccess

如果项目里权限不只是'有没有某个标识'，还会混进角色判断，useAccess 会更顺手一点。它的职责比 usePermission 广，但接口不一定要复杂。

// hooks/useAccess.js
import { computed } from 'vue';
import { usePermissionStore } from '@/stores/permission';

export function useAccess() {
  const permissionStore = usePermissionStore();

  // 判断是否为管理员
  const isAdmin = computed(() => permissionStore.roles.includes('admin'));

  // 判断是否具有特定权限
  const canAccess = (condition) => {
    if (typeof condition === 'string') {
      return permissionStore.permissions.includes(condition);
    }
    if (Array.isArray(condition)) {
      return condition.some((perm) => permissionStore.permissions.includes(perm));
    }
    return false;
  };

  return { isAdmin, canAccess };
}

这里我更倾向于把 isAdmin 单独拿出来。原因很简单：角色判断和权限判断虽然有关联，但在代码里不是一类问题。isAdmin 适合做强语义分支，canAccess 适合做通用判断，别混成一个大函数，后面不好读。

组件里这样用就行：

<template>
  <div>
    <p v-if="isAdmin">欢迎管理员！</p>
    <button v-if="canAccess('edit')">编辑</button>
  </div>
</template>

<script>
import { useAccess } from '@/hooks/useAccess';

export default {
  setup() {
    const { isAdmin, canAccess } = useAccess();
    return { isAdmin, canAccess };
  },
};
</script>

React：用 Custom Hook 做同样的事

React 里思路没变，只是数据来源通常换成 useSelector。如果权限状态在 Redux 里，这个 Hook 写法会很自然。

usePermission

// hooks/usePermission.js
import { useSelector } from 'react-redux';

export function usePermission() {
  const permissions = useSelector((state) => state.permission.permissions);

  // 封装权限判断函数
  const hasPermission = (permission) => {
    return permissions.includes(permission);
  };

  // 支持多权限判断
  const hasAnyPermission = (permissionsList) => {
    return permissionsList.some((perm) => permissions.includes(perm));
  };

  return { hasPermission, hasAnyPermission };
}

组件里可以直接控制按钮是否可用，而不是只靠 display: none 把它藏起来：

import React from 'react';
import { usePermission } from './hooks/usePermission';

const UserProfile = () => {
  const { hasPermission, hasAnyPermission } = usePermission();
  return (
    <div>
      <button disabled={!hasPermission('edit')}>编辑</button>
      <button disabled={!hasAnyPermission(['delete', 'admin'])}>删除</button>
    </div>
  );
};

export default UserProfile;

这里用 disabled 还是 v-if / 条件渲染，要看产品要求。能不能看见、能不能点，是两件事。很多系统会把'不可操作但可见'的状态留给用户，这样至少不会让界面突然缺块。

useAccess

// hooks/useAccess.js
import { useSelector } from 'react-redux';

export function useAccess() {
  const roles = useSelector((state) => state.permission.roles);
  const permissions = useSelector((state) => state.permission.permissions);

  // 判断是否为管理员
  const isAdmin = roles.includes('admin');

  // 判断是否具有特定权限
  const canAccess = (condition) => {
    if (typeof condition === 'string') {
      return permissions.includes(condition);
    }
    if (Array.isArray(condition)) {
      return condition.some((perm) => permissions.includes(perm));
    }
    return false;
  };

  return { isAdmin, canAccess };
}

import React from 'react';
import { useAccess } from './hooks/useAccess';

const UserProfile = () => {
  const { isAdmin, canAccess } = useAccess();
  return (
    <div>
      {isAdmin && <p>欢迎管理员！</p>}
      <button disabled={!canAccess('edit')}>编辑</button>
    </div>
  );
};

export default UserProfile;

该怎么优化

权限判断本身很轻，但如果一个页面到处都在算，重复渲染时还是会白白消耗。computed 或 useMemo 的价值就在这里：把稳定的判断结果缓存下来，没必要每次都重新跑一遍。

动态更新也别忽略。权限数据如果来自登录态、切换组织、刷新 token 这些流程，Hook 最好能跟着状态变，不然页面会出现'登录后权限没刷新''切换账号后菜单还停在旧状态'这种很烦的小问题。

最后落一下结论

自定义权限 Hook 的意义不在于把权限逻辑写得多花哨，而是把散落在组件里的判断收起来，统一成一个可复用的入口。Vue 3 用 Composition API，React 用 Custom Hook，写法不同，思路其实一样：权限来源集中、判断逻辑统一、组件只关心结果。

如果项目只是几个简单按钮，直接写条件判断也不是不能接受。但只要权限规则开始变多，我会更倾向于早点抽出来。这个活儿不算漂亮，省的是后面的维护时间。