1.权限库表的设计
说明：以下几个表是权限库表的核心内容，此处省去了创建时间，修改时间之类的字段，只做核心设计。另外补充表是为了让整体权限系统的数据更具维护性而做的添加。
设计思路：所有用户基于角色进行控制，只有角色才有资源和权限的设置权利。杜绝单独对用户进行权限资源控制，原因很简单，这里不作赘述。在前端UI交互时，可加入角色权限资源克隆的功能。
graph TD
Start --> 用户登录 -->获取用户权限数据和用户的资源数据-->gin中间件判断当前用户是否拥有某个请求权限
对于前端的界面，路由，控件等，可作为资源的形式存入权限系统中。用户登录后一次性加载，对于要进行判断的地方，直接通过v-if 等进行控制。
1.1 角色表
1.2 用户的角色表
1.3 权限表
| 字段 | 含义 | 说明 |
|---|
| id | 主键 | |
| mid | 模块id | |
| name | 权限名称 | |
| route_path | 路由路径 | 唯一，gin context.FullPath() |
| des | 描述信息 | |
1.4 角色的权限
1.6 补充表--模块，相当于权限的容器
| 字段 | 含义 |
|---|
| id | 主键 |
| name | 模块名称 |
| pid | 上级模块id |
| des | 描述信息 |
1.7 补充表--操作记录表
| 字段 | 含义 |
|---|
| id | 主键 |
| uid | 用户id |
| content | 操作内容 |
1.8 资源表，用于前端展示使用
| 字段 | 含义 | 说明 |
|---|
| id | 主键 | |
| type_id | 类型id | |
| name | 资源名称 | 唯一 |
| des | 描述信息 | |
1.9 资源类别表，用于前端展示使用
1.10 角色的资源表
| 字段 | 含义 |
|---|
| id | 主键 |
| role_id | 角色id |
| rid | 资源id |
2.权限的刷新，判断，性能等问题
我们所有的系统不可能再纯粹的单体，所以redis+本地内存的二级缓存形式，我们通常想到的手段。本地内存的刷新可用直接采用pub/sub的模式进行刷新，当然也有类似的框架包来解决这一问题。
gin的中间件在拦截到请求时，可以通过context.FullPath()拿到当前所使用的路由，而这正好是权限表中配好的 route_path的内容，这一切就正好串联起来了。
3.二级缓存的使用推荐
github.com/viney-shih/…
