最小权限原则在前端安全中的实战应用与踩坑经验
シ乐佳前端权限控制，到底怎么搞才不累？
最近项目里又遇到权限问题，老板说「后台用户能看的页面，普通用户不能进」，产品经理补一句「按钮也要按权限隐藏」。我一听就头大——这不就是最小权限原则嘛，但真做起来，方案五花八门，有的写起来像在绕迷宫，有的简单到怀疑人生。今天就来聊聊我在实际项目中用过的几种前端权限控制方案，不讲理论，只讲谁更省事、谁更灵活、谁坑最多。
三种主流方案：路由守卫、组件级指令、状态驱动
我目前主要用这三种：
- Vue Router 的路由守卫（或 React 的 Route Wrapper）
- 自定义指令，比如
v-permission - 基于状态管理（如 Pinia/Vuex）的权限状态驱动
下面一个个拆开说，顺便贴点我线上跑的代码。
路由守卫：适合粗粒度，但别指望它干细活
我最早用的就是这个，简单粗暴：用户没权限，直接跳转登录页或者 403。代码大概长这样（以 Vue 为例）：
router.beforeEach((to, from, next) => {
const userRoles = store.getters['user/roles'];
const requiredRoles = to.meta.roles;
if (requiredRoles && !requiredRoles.some(role => userRoles.includes(role))) {
next('/403');
} else {
next();
}
});
这种方案的优点是一劳永逸——只要配好 meta，整个页面级别的权限就管住了。我比较喜欢用在管理后台的主菜单入口，比如「财务模块」只有 finance 角色才能进。
但问题也很明显：它只能管页面，管不了按钮。你总不能为了一个「删除」按钮再单独建个路由吧？所以，我一般只用它做第一道防线，真正的细粒度控制还得靠别的。
自定义指令 v-permission：灵活，但容易写成屎山
后来我开始用指令控制按钮级权限，比如：
<button v-permission="['admin', 'editor']">删除</button>
对应的指令实现：
app.directive('permission', {
mounted(el, binding) {
const { value } = binding;
const userRoles = store.getters['user/roles'];
if (value && Array.isArray(value)) {
const hasPermission = value.some(role => userRoles.includes(role));
if (!hasPermission) {
el.parentNode?.removeChild(el);
}
} else {
console.warn('v-permission: expect array of roles');
}
}
});
说实话，这个方案很灵活，哪里需要权限控制，加个指令就行。而且对模板侵入小，逻辑集中。
但踩过坑：早期我直接用 el.style.display = 'none' 隐藏元素，结果被安全审计打回来——DOM 还在，只是看不见，用户打开 DevTools 改个 style 就能操作。后来改成直接移除节点，虽然暴力但有效。
另一个问题是：如果权限规则复杂（比如「A 或 (B 且 C)」），指令传参就很难表达。这时候我宁愿写个 computed 判断，也不硬塞进指令里。
状态驱动：最可控，但写起来啰嗦
现在我越来越倾向用状态驱动的方式。比如在组件里：
const canDelete = computed(() => {
return store.getters['user/hasPermission']('post:delete');
});
// 或者更细粒度
const canEdit = computed(() => {
return currentUser.value.id === post.authorId ||
store.getters['user/hasRole']('admin');
});
然后模板里直接用：
<button v-if="canDelete">删除</button>
这种方式的好处是逻辑完全透明、可测试、可组合。你可以把权限判断封装成函数，比如 hasPermission(action)，后端返回的权限字符串（如 post:read, post:write）直接映射过来，符合 RBAC 模型。
我现在的项目基本都这么干，尤其是对接后端做了完善的权限体系时。比如从 https://jztheme.com/api/user/me 拿到用户权限列表，存进 Pinia，然后 anywhere 都能用。
缺点？写起来确实啰嗦点，每个组件都要写 computed。但换来的是可维护性**——哪天产品说「作者可以删自己的文章，管理员可以删所有」，我改一行逻辑就行，不用动模板。
我的选型逻辑：看场景，别死磕一种
很多人问我「到底该用哪种」，我的回答永远是：混合用。
- 页面级权限**：路由守卫搞定，简单高效
- 按钮/区块级权限**：优先用状态驱动（computed），复杂逻辑放 JS 里，别塞模板
- 简单场景、快速原型**：v-permission 指令救急，但别滥用
比如我现在维护的一个 SaaS 后台：
- 菜单路由用 meta.roles 控制
- 页面内的操作按钮全部用 computed 判断权限
- 只有极少数静态文案块用 v-permission 隐藏（因为不涉及交互，安全风险低）
这样分工明确，代码也清爽。别为了「统一」而强行用一种方案，那才是自找麻烦。
踩坑提醒：这三点一定注意
1. 前端权限只是体验优化，不是安全边界。所有敏感操作，后端必须校验！我见过太多人以为前端 hide 掉按钮就安全了，结果接口没鉴权，被人 curl 一把梭哈。
2. 权限数据要缓存，但别缓存太久。用户切换角色后，前端得及时更新权限状态。我一般在登录/切换租户时重新拉取，或者用 WebSocket 推送权限变更。
3. 别在模板里写复杂逻辑。像 v-if="user.role === 'admin' || (user.id === item.ownerId && item.status !== 'locked')" 这种，赶紧抽成 computed。不然三个月后你自己都看不懂。
总结：没有银弹，但有顺手的工具
最小权限在前端落地，本质是平衡安全性、开发效率和可维护性。路由守卫适合守大门，指令适合贴封条，状态驱动适合精细操作。我现在的项目里，80% 的权限控制都用状态驱动 + computed，虽然多写几行代码，但逻辑清晰、改动方便，长期来看最省心。
以上是我踩坑后的总结，有更优的实现方式欢迎评论区交流。如果你也在搞权限系统，不妨试试把复杂判断从模板挪到 JS 里——你会回来谢我的。
