权限控制几乎是所有中后台系统的标配需求。运营专员只能看报表，普通编辑只能改文章，管理员可以配置一切，这些差异化的能力背后都需要一套完整的权限体系来支撑。很多团队在做前端权限时只做了菜单隐藏，结果用户直接输入URL照样能进页面，这种半吊子方案上线后往往要返工。这篇文章把前端权限控制拆成数据、路由、菜单、按钮几个层面，逐一讲清楚设计思路和落地代码。
一、先想清楚：前端权限控制到底控制什么
前端权限控制本质上是控制“界面的可见性和可达性”，它可以分为三个层次。第一层是路由权限，也就是用户能不能访问某个页面；第二层是菜单权限，控制导航栏里显示哪些入口；第三层是操作权限，精确到页面里某个按钮能不能点、某个功能能不能用。这三层从粗到细，共同构成完整的权限体验。
需要特别强调的是，前端权限的所有工作都只是体验优化，不是安全边界。JavaScript代码运行在用户浏览器里，任何接口请求都可以被伪造，任何人打开开发者工具就能看到你的路由表和权限数据。真正的权限校验必须由服务端在每个接口里完成，前端做的只是让没权限的用户看不到入口、进不了页面，减少误操作和不必要的请求。理解这一点后，你在设计前端权限时就不会纠结“能不能绕过”这种问题，而是把精力放在如何让权限逻辑清晰、易维护上。
另一个要先想清楚的问题是权限粒度。粒度太粗，比如只区分“管理员”和“普通用户”，后期需求一变就要大改；粒度太细，比如每个接口都定义权限点，维护成本会飙升。实践中比较推荐的是“角色加权限点”的混合模型：用户绑定角色，角色关联一组细粒度的权限点（比如 article:edit、user:delete），前端根据权限点控制界面，角色只用于批量分配，这样既能灵活授权又不至于难以管理。
二、权限数据从哪来：静态配置还是动态下发
权限数据有两种常见的获取方式。一种是登录后后端只返回当前用户的角色或权限点列表，路由表写在前端代码里，前端根据权限点过滤出用户可见的路由。这种方式实现简单，前端可以完全掌控路由结构，适合权限变化不频繁的项目。另一种是后端直接下发完整的路由配置或菜单树，前端拿到后动态生成路由。这种方式权限逻辑全部收归后端，新增页面不需要前端发版，但代价是路由组件的映射关系要额外维护，前后端耦合反而更深。
对大多数项目来说，第一种方案更务实。登录成功后，把后端返回的权限点存入全局状态，然后在路由守卫里做拦截。以Vue为例，核心代码大致如下：
router.beforeEach(async (to, from, next) => {
const userStore = useUserStore()
// 未登录统一跳转登录页
if (!userStore.token) {
return next({ path: '/login', query: { redirect: to.fullPath } })
}
// 已登录但还没加载权限数据
if (!userStore.isLoaded) {
await userStore.fetchPermissions()
// 根据权限点过滤路由并动态注册
const routes = filterRoutes(asyncRoutes, userStore.permissions)
routes.forEach(route => router.addRoute(route))
// 重新导航，确保新路由已生效
return next({ ...to, replace: true })
}
// 无权限访问则跳到403页面
if (to.meta.permission && !userStore.has(to.meta.permission)) {
return next('/403')
}
next()
})
// 路由过滤：递归踢掉无权限的节点
function filterRoutes(routes, permissions) {
return routes.filter(route => {
if (route.meta?.permission) {
if (!permissions.includes(route.meta.permission)) return false
}
if (route.children) {
route.children = filterRoutes(route.children, permissions)
}
return true
})
}这段代码有几个细节值得注意。一是权限数据要在首次导航时才拉取，而不是应用启动时就请求，因为启动时可能还没有token；二是动态添加路由后必须用 next({ ...to, replace: true }) 重新走一遍导航流程，否则首次访问动态路由会白屏；三是每个路由通过 meta.permission 声明所需权限点，把权限配置和路由定义放在一起，查起来一目了然。
如果选择后端下发路由的方案，需要约定一套JSON结构，前端再通过组件映射表把字符串路径转换成真正的组件。这种方案要格外注意组件映射的完整性，后端配置了一个不存在的组件路径，页面就会直接报错，建议在开发环境加一层校验并给出明确提示。
三、按钮级权限：指令、组件与函数三种实现方式
页面级权限解决之后，剩下的问题是怎么优雅地控制按钮。硬编码 v-if="hasPermission('article:edit')" 当然能用，但满屏都是这种判断，后期改权限点名称会非常痛苦。Vue项目里更推荐用自定义指令封装：
// 注册权限指令：无权限的元素直接从DOM中移除
app.directive('permission', {
mounted(el, binding, vnode) {
const userStore = useUserStore()
const { value } = binding
if (!value) return
if (!userStore.has(value)) {
// 移除节点，避免用户通过改样式让它重新显示
el.parentNode?.removeChild(el)
}
}
})
// 模板中使用
// <button v-permission="'article:edit'">编辑文章</button>指令的方案好处是侵入性低、写法简洁，但有一个局限：它是命令式的，没法参与组件的逻辑判断。如果某个按钮的显示与否还要结合其他条件做计算，用函数或者组件更合适。React生态里常用的则是封装一个 <Authorized> 组件，利用高阶组件的思想统一处理：
function Authorized({ permission, children, fallback = null }) {
const permissions = useSelector(state => state.user.permissions)
const has = permissions.includes(permission)
return has ? children : fallback
}
// 使用：无权限时显示灰色提示而不是直接隐藏
<Authorized permission="order:export" fallback={<Tooltip title="当前角色无导出权限"><Button disabled>导出</Button></Tooltip>}>
<Button onClick={handleExport}>导出</Button>
</Authorized>这里有个容易被忽略的设计选择：无权限的按钮到底是隐藏还是置灰？两种策略各有道理。隐藏适合用户完全不该知道该功能存在的场景，界面更干净；置灰则保留了功能可发现性，用户知道有这个能力但当前角色用不了，配合提示文案还能引导用户去申请权限。建议在权限系统设计初期就和产品团队约定好统一策略，避免不同页面各干各的，用户体验割裂。
另外要提醒一点，指令里用 removeChild 移除元素而不是简单设置 display:none，是因为隐藏的元素仍可通过浏览器审查元素改样式找回来。虽然前面说过前端权限不是安全边界，但把门槛抬高一点总没坏处，至少能挡住随手乱改的用户。
四、菜单渲染与整体架构收尾
菜单和路由其实是同一份数据的两个视图。推荐的做法是路由表本身就是菜单数据源，通过 meta 字段标记哪些路由要出现在导航里、显示什么图标和标题，这样路由权限过滤完成后，菜单自然就是过滤后的结果，不需要单独维护一份菜单配置，也不会出现“菜单里没有但页面能进”的不一致情况。
const asyncRoutes = [
{
path: '/article',
component: Layout,
meta: { title: '文章管理', icon: 'document' },
children: [
{
path: 'list',
component: () => import('@/views/article/List.vue'),
meta: { title: '文章列表' }
},
{
path: 'draft',
component: () => import('@/views/article/Draft.vue'),
meta: { title: '草稿箱', hidden: true } // 有权限但不展示在菜单
}
]
}
]最后从架构角度总结几个实践建议。权限点命名要有统一规范，推荐“资源冒号操作”的格式，比如 user:create、role:assign，前后端共用同一套编码，避免两边对不上；全局权限状态要在退出登录时彻底清空，包括动态添加的路由，否则切换账号会出现上一个用户才能访问的页面残留；权限数据建议做本地缓存时设置合理的失效时间，权限变更后要考虑强制刷新或重新拉取的机制。
整体来看，一套好用的前端权限系统由四部分组成：统一的全局权限状态、基于路由守卫的页面拦截、声明式的按钮控制组件或指令、以及与服务端一致的权限点规范。把这四块搭好，新增一个带权限的页面只需要写路由时多加一个 meta 字段，维护成本极低。而安全这件事，永远交给服务端去兜底，前端权限做的是让产品用起来顺手、看起来专业。