前言
微微CMS3目前已经发布有3个月的时间了，中间也从更新了2个版本。今天总算抽出一点时间来完成V3的故事。
为什么会重写？
嗯，这是一个很沉重的问题。每一个软件都有自己的生命周期，不断地升级以满足当前的的变化。微微CMS又为什么要更新？解决了什么问题？今天就来聊聊吧。
技术债务
随着技术的提升，对代码质量的要求便有了更高的要求。微微CMS在设计之初想要满足的只是功能层面而已，很多功能都是流水功能，只是想要这个功能，便去做了。有多少人用，用得怎么样？几乎没有反馈。这些不需要得功能反而造成了认知负担。在架构设计上也存在一定得不足，这也是我自己认知和技术提升上得一个门槛。例如：对日志的输出过于随意，一些功能又不够稳定。
前端选择
重写肯定就要重新选择一下前端了。特别是后台管理的页面，目前使用的是layui。于是我便去看了vue相关的后台框架，在连续测试了好几个框架出来，然后试着去适配。我发现了一些问题
目前的前端框架基本上都是使用Typescript进行开发，嗯，我又去学习了TS
目前的VUE3更新了，我又去学习了VUE3
前端的框架选择有element plus 和 antd，对相关的组件又看了一遍
在研究使用VUE写后台我发现我编写代码的速度变慢了，因为前后端分离的原因，又因为需要使用TS的原因，后端写了，前端又需要去定义一遍类型，对每个请求进行封装
打包的时候，遇到了一个问题，前端的包太大了。
......
随后我看到layui又更新了。于是又开启了layui的适配选择，因为layui升级到了最新，之前的框架也开始进行更新工作
升级layui到最新版本
一些不兼容的组件进行更新适配
使用layui的单页模板渲染进行测试
封装layui数据
后端的选择
还是继续使用Golang来进行开发，还是继续基于IRIS框架。对于后端又做了一些优化调整
规范化日志输出
使用rbac管理接口和视图的权限
对session的管理进行优化，加入自动续期
对csrf的管理进行优化，加入自动续期
重写数据库文件
重新定义主题模板的规范
重新定义富文本编辑器
修剪不必要的功能，保留主要的核心功能
......
RBAC角色权限管理
在Golang中RBAC权限管理很常见的就是Casbin提供的角色权限管理模型和权限库了。在最初，我们也进行了选择。但是随着具体的编码过程使用，发现了一些问题。那就是Casbin太重了。我只需要最简单的RBAC，ACL功能而已。Casbin提供了的功能接口也有一些问题，主要是更新不太方便。批量插入，批量更新，是非常常见的，Casbin的实现有点复杂。于是我就重写了。自己来实现RBAC模型，并与SQL进行打通兼容，使用缓存进行管理权限。