首先系统权限，每个账号登录后，都需要知道这个账号允许访问哪些api，哪些数据权限（一般是指其他账号的一些数据）
这里就需要通过角色来关联。
--1.角色绑定菜单，每个菜单设计的时候包含了这个菜单会用到的所有api接口，如果菜单里面需要添加子权限，如新增，删除等，则可以继续拆分，新增权限，和对应的新增的api接口，
--2.角色绑定数据权限，配置可见用户范围
--3.角色绑定其他
这套设计方案的优点：灵活性和安全性都能得到比较好的保障
答疑：
1.这套方案后续如果菜单发生调整，如移动层级，新增菜单功能，对已配置的角色有什么影响
答：如果是调整或新增菜单功能后，每个角色有可能都需要重新配置才能生效，或是从数据库刷数据，这可能也算是这套方案的缺点
2.如果某个业务，例如云盘，有群组功能，我被加到某个组，或是选人组件，里面想可以选所有人，岂不是跟整体的数据权限冲突？
答：系统的权限其实是为了多数的业务提供个普适的处理，减少模块权限配置，如果不适用具体的模块，可以按模块的需求单独设计权限，忽略不用系统数据权限即可。
3.如果某个菜单A模块里面包含了其他菜单B模块的ui，只配置了菜单A的权限，没有配置菜单B的权限，那这套方案是不是就不适用？
答：也适用，这种情况属于模块间存在交叉的复杂模块，如果确实是需要在A模块里面使用到B模块的某个ui，例如需要打开B模块的详情，这时候只需要在A模块里面把B模块详情需要api接口权限添加上即可。
参考伪数据结构
用户
did
id
avatar
account
name
dept
pwd
groupIds
部门
id
pid
name
角色
id
name
menus:[],
powerType:1,
depts //可查看部门
uids：
菜单
id
pid
name
path
"meta": {
"title": "角色管理",
"icon": "el-icon-notebook",
"type": "menu"|"button"
},
"component": "setting/role"
apiList:[]
参考ui
