「这是我参与11月更文挑战的第5天，活动详情查看：2021最后一次更文挑战」。

#摘要

最近在进行，权限业务的重构，经过思考，总结出了一些概念，分享给大家。

在之前的权限管理这一个功能模块，我们是通过前端来进行权限控制。但仅仅前端进行权限控制并不是真正意义的权限控制，它只是减少页面结构暴露、增强用户体验的功效。

痛点

我们先来总结以下仅仅通过前端来进行权限控制，在代码编写和业务研发时出现的痛点。我们已access为例。

菜单权限

• 菜单/路由耦合性高：菜单中除原有的路由菜单信息以外，还需要添加权限管理，并且不同角色可访问的权限菜单时不相同的，会导致大量的重复代码，并且维护难度高。
• 不灵活：权限不能根据业务需求变化，而变化。每次出现角色人的权限变化时，很不灵活，需要找到对应的内容，并修改。

功能

• 在编写业务代码的时候，耦合度高。
• 对于颗粒度比较小的功能需要进行代码编写，导致代码比较杂乱，可阅读性降低。

解决方案

菜单

• 后端只需要返回给我们一个菜单树，这个树中每个节点的数据，只需要包括菜单的名称、路由。
• 前端在页面渲染前，获取菜单列表并渲染就可以了。

功能

对于大的集成功能来说，其实和菜单权限的类型差不多。但是对于颗粒度比较小的功能，比如一个增删改查的功能，我们应该如何来实现他的权限控制呢?

场景

大家可以想象一下一个增删改查的表格，我们想给管理员删除的权限，而对于普通用户，我们只想给他修改的功能。那么我们要怎么实现这个业务场景呢？

• 首先，我们需要和后端约定好约定好字段，管理员有删除的权限，那么我们就可以在管理员的权限中存在role_can_del这个字段。而对于普通用户那么他就不存在这个字段。
• 前端，在展示的时候，通过后端返回的字段来进行元素的渲染，那么对于没有普通用户而言，他是没有删除权限的，那么我们就需要根据对应字段来对元素进行显示和隐藏。

总结

菜单和功能是可以相互嵌套的。我们来就一个例子。现在又两个页面如下。

// 两个页面 page1、page2

// 管理员需要展示这两个页面，那么数据返回格式可以是这样的
Menu : [
  {
  	name : 'page1',
  	route : '/page1'
  	role : {
    	role_can_del: true, //可以删除
    	role_can_edit : true, // 可以修改
    	role_can_add : true // 可以添加
    }
  },
  {
  	name : 'page1',
  	route : '/page1'
  	role : {
    	role_can_del: true, //可以删除
    	role_can_edit : true, // 可以修改
    	role_can_add : true // 可以添加
    }
  }
]

// 普通用户需要展示这一个页面，那么数据返回格式可以是这样的
Menu : [
  {
  	name : 'page1',
  	route : '/page1'
  	role : {
    	role_can_edit : true, // 可以修改
    	role_can_add : true // 可以添加
    }
  }
]

可以看到用户只展示一个页面，并且对这个页面没有删除操作的权限。