根据已完成的前端页面和api接口进行联调
问题一
- 设计之初是以登录接口获得token然后由前端存放到cookie中再由cookie中是否含有token作为自动登录以及退出的判断条件，
问题构成：
- 在实现过程中根据token去获取用户信息（包含了权限），会验证token是否正确
- 在vue中导航守卫是根据判断cookie中是否有token进行后续操作
- 后端请求拦截了请求头判断token是否正确会给予错误返回（出登录接口，其余均有验证）
- 前端请求响应拦截了后端判断token不正确的错误返回，并根据返回退出并跳转到登录页面
问题操作：
- 点击登录后陷入循环体，无报错，无限提示token失效
- 后改为vuex去作为中间变量，登录后刷新系统瘫痪
- 缓存读取vuex，通过sessionStorage进行数据存储，操作依旧不畅且出现更多错误
问题总结：
- cookie中是否包含token作为唯一条件只能讲两种操作分开，而我添加了（1-自动登录，2-退出登录，3-token是否过期，4-有token即进行路由跳转）其中【3-token是否过期】根据返回失效数据从cookie中将token删除，【4-有token即进行路由跳转】没有进行token验证只要cookie中有token就默认用户正确，所以进行了路由导航以及vuex和请求响应拦截的整体逻辑改动
- vuex并不适合缓存读取虽然可以刷新时保留数据，但是也对刷新这一功能进行了错误使用，刷新即刷新数据，但是缓存读取就相当于刷新的漏洞，数据并未刷新
- 逻辑错误可以定义为超级大坑，一但陷进去了要从整体去看，不能钻牛角尖，太费时间了
问题二
- 用户角色删除留有脏数据
问题构成：
- 关于角色或用户删除时关联表中数据未删除，数据库会留下无用数据
问题总结：
- 在删除用户或角色时接口会自行处理以关联点为中心一对多删除所有关联
问题三
- 权限设置页面构建缺少对应接口
问题构成：
- 设计接口时未考虑到权限页面设计逻辑
- 按照接口设计逻辑去设计页面过于复杂
问题总结：
前后分离需要前后端良好沟通，之前觉得联调很快（前端写请求从后端接口那数据展示），从权限设计这里改变了该看法。
1.前端权限页面设计逻辑从接口要数据进行业务操作，用户体验感。
2.后端权限接口设计逻辑用postman跑通流程即可，程序员工作舒适感。
1，2分别是以前端和后端为设计主导，当前端为主导时后端的活肯定加多，以后端为主导前端的活肯定加多，人不为己天诛地灭，你给我加活方便自己我不得锤你，所以需要前后端相处融洽，能够理性沟通
- 开始权限是我后端思想为主导去设计的，想着前端页面实现不难，结果啪啪打脸。
- 然后写页面时是我用前端思想为主导去写，直接给我整不会了，有些我想要的数据都没有。
- 但是前后端分别主导的权限设计都是可以实现的但是都的给对方加活。
- 好在我主导我自己，对比而言通过了前端主导（后端加1个接口，改1个接口即可，以后端为主，前端页面就很麻烦）
- 工作中前后端联调过程中涉及整体逻辑设计的需要理性沟通，沟通不来的直接开撕。
问题四
- 权限构思过于简单，全由admin去决定其他用户的权限
问题构成：
- 假设适用于大型企业管理，权限设计无上下级关系
- token的设计是单一账号登录，不可同一账号同时多处登录，确保了账号私密性但是也违背了管理系统的初衷
问题优化方案：
- 解放token单一账号登录（依旧不适用人员架构复杂的公司）
- 重新设计权限系统，以上下级区分，做到上级管理附属的下级，同级互不干涉，未附属的下级不可管理
由于权限设计没有达到我预期的结果，所以废除了，【Project(6)-接口展示】已不可用
计划：
- 重新设计一套权限
