17370845950

JavaScript权限控制是运行时根据用户身份/角色/能力决定可见性与可操作性的协同机制，涵盖路由守卫、动态菜单、条件按钮、接口校验四层，需前后端配合，前端重体验，后端保安全。

JavaScript中的权限控制，本质是根据用户身份、角色或能力，在运行时决定“能看什么、能点什么、能进哪页”。它不是单点功能，而是贯穿路由跳转、菜单渲染、按钮显示、接口调用多个环节的一套协同机制。前端做的是体验层防护，后端才是安全底线——两者必须配合，缺一不可。

路由跳转前就拦住无权访问

用户点击菜单或输入URL时，不能等页面加载完再提示“没权限”。要用路由守卫在跳转前做判断：

• 每个路由配置里带上权限标识，比如 role: 'admin' 或 permissions: ['user:read', 'user:delete']
• 在 router.beforeEach（Vue Router）或 useEffect + navigate（React Router v6+）中读取当前用户信息（通常来自 localStorage 或全局状态）
• 比对目标路由所需权限，不满足就重定向到登录页或 403 页面，不放行
• 注意：这只是前端拦截，真实权限校验必须由后端接口返回结果，否则容易被绕过

界面上不显示用户根本没资格看到的东西

别让用户看到一个灰色按钮写着“删除”，点了才弹“无权限”——这体验差还暴露逻辑。应该从源头隐藏：

• 侧边栏菜单按用户权限动态过滤，只保留他能进的路由项
• 操作按钮用条件渲染，例如：{user.permissions.includes('post:publish') && 发布}
• 表单字段也可按权限控制是否可编辑，比如管理员能改状态，普通用户只能看
• 避免写死字符串，建议把权限码统一管理成常量对象，方便维护和类型提示

用合适的方式表达权限模型

不同项目复杂度不同，选对模型很关键：

• RBAC（基于角色）：适合大多数中后台系统。用户 → 角色（如 editor/admin）→ 权限列表。简单清晰，数据库好建模
• ABAC / Casl（基于能力）：适合需要细粒度控制的场景。比如“用户只能编辑自己创建的文章”，或“仅当文章为草稿时才允许修改标题”。Casl 库用 can('update', 'Post', { authorId: userId }) 这种方式定义非常直观
• 位运算权限：适合权限种类少、变动不频繁、追求性能的轻量系统。把读/写/删分别设为 1/2/4，用户权限值是它们的按位或，检查用 (userFlag & READ) !== 0，快且省内存

权限数据从哪来、怎么更新

权限不是写死在代码里的，得随用户登录实时拉取：

• 登录成功后，后端返回该用户的角色列表或完整权限数组（如 ['order:read', 'report:export']）
• 前端存入内存或持久化到 localStorage/sessionStorage，避免每次刷新都重拉
• 如果权限会动态变更（如后台实时调整某*限），可通过 WebSocket 或定时轮询更新本地权限缓存
• 登出或 Token 过期时，务必清空权限状态，防止残留导致越权

基本上就这些。权限控制不复杂但容易忽略细节，关键是把“谁在什么时候能做什么”这个逻辑理清楚，再分层落到路由、UI、请求三处。前端负责友好与及时反馈，后端守住最后一道门——两边都到位，系统才既安全又可用。