序
2020 年 10 月 17 日，我正式发布了 Fantastic-admin 这一款根据 Vue 的过程当中后台管理界面架构。在这里两年多的时间内，我相继写几篇我还在开发设计这一套架构中的一些体会心得和专业技术总结：
- 2020 年《我是如何设计后台框架里那些锦上添花的动画效果》
- 2020 年《一劳永逸，解决基于 keep-alive 的后台多级路由缓存问题》
- 2021 年《在后台框架同质化的今天，我是如何思考并做出差异化的》
- 2022 年《神奇！这款 Vue 后台框架居然不用手动配置路由》
但今年，有很大半年时间我几乎消声匿迹，并没有产出率一篇文章。除开一直在日常维护迭代更新架构外，我也在思索一个问题，那便是：
怎样才能做到一款智能管理系统架构？
有手就行？
这也是“VUE后台管理界面模版”平台上搜集的一些相对性做的非常优秀，换句话说有一定名气的架构。当然这也仅仅冰山一角，第一次去 Gitee 或是 Github 检索 “后台管理” “admin” 等关键词，我们还能发觉大量。好像写一个后台管理模板对前端工程师而言，有手就行？
的确，一个标准的后台管理界面，绝大多数基本功能是相当统一的，由于又不像C端商品必须相对高度个性化。一个侧面或是头顶部导航条，根据配备一键生成；再预置多套主题风格，便捷转换；随后写几个通用性控制模块，例如用户管理系统、角色管理、词典管理方法；最终加上个登录页，健全下权限管理，基本上就大功告成。
想要实现这种难么？不会太难，对前面而言，的确有手就行。也促进许多开发人员挑选自己写，写完了有兴趣的还会继续宣传和推广一番，意见反馈好的话再次维护保养，没什么意见反馈就真慢慢变成了一个自购架构或是弃游了。
这也就是为什么网上流传非常多后台管理模板的主要原因，因为一直有新架构发生，也是有很多架构早已好多个月，已经超过了半年的时间未升级，颇具一种「你方唱罢我登场」觉得。
给谁服务项目？
重新回到主题风格，即然一定要做好一款智能管理系统架构，还有谁来定义这一“好”呢，是用户吗？是，却又不都是。
任何一款技术框架和产品，最后一定是立足于顾客、立足于业务，但作为一款智能管理系统架构，我觉得更多的或是立足于开发人员，让开发人员用更低的时长，进行顾客或项目需求，那便是一款好的智能管理系统架构。
但是一个两双手就可所写的架构，想让开发人员选择用你，而非自己去写，想来绝对不是完成上边这些作用这么简单，那应该怎么服务周到开发人员呢？
如何服务？
即然明确要给开发者服务，那么就需要明确开发人员的痛点。还好我本身就是开发人员，在公司内部业务开发里就有具体使用，因此设计中的痛点还是很好找到，只不过以下几个方面：
对于之上梳理的几点，下边我要用好多个具体的事例来讲解下我是怎么为开发人员提供服务，换句话说我是怎么服务项目自已的。
终究只需我自己觉得用到舒服了，别的开发人员的使用体验也一定都不会太差，但前提是提高对自己的要求，以“人无我有，人有我优”作为总体目标。
通用性业务组件少
这种困扰是相对来说非常容易克服的，由于目前市面上各种各样 UI 库早已能够满足绝大部分的业务流程使用需求了，我就是做了一些二次封装或填补。
例如在 Element Plus 的 Cascader 部件前提下，封装形式了**省市街道社区连动**部件，便捷完成二级、三级和四级的挑选连动：
又比如在 Element Plus 的 Upload 部件前提下，封装形式了**照片上传**部件，带来了图组排列、图组浏览、文件属性和数量限制等特点：
不仅对 Element Plus 进行一些二次封装外，我都可以补充一些部件，比如说**发展趋势标识**部件：
以及**检索控制面板**部件：
自然不单单是上边推荐的这种，大量能够浏览 演试站 进行查看。
我想说的便是，通用性业务组件，是架构很容易克服的一个困扰，因为他可观测，根据原型设计或设计图，找到一些经常在各个业务模块中存在的作用，就可以选择能否封装形式成部件，从而降低开发人员自己去完成的时间也。
类似业务模块必须经常复制编码或文档
后台管理系统里，一定有一些控制模块在页面、实际操作逻辑性上有相对高度相近的，例如每个控制模块中的搜索结果页，他们都是有收藏功能、可视化数据、分页查询作用。却又不完全一样，例如数据库、检索项、列表展示字段名都不一样。
对于这类情景，我的方法是由架构预置目标，组合互动式的指令去形成相对应的文档。小至部件和单页面的模版，大至全部控制模块（包括搜索结果页、宝贝详情、新增加、编写、删掉作用一应俱全），都能通过好多个命令迅速形成，如下图所示：
自然开发人员还可以根据实际需求场景，自主拓展必须产生的模版。
独特情景缺乏统一解决方法
这一块的痛点，大量表现在架构自己的能力上，是我觉得确定架构是不是实用中最大的要素。
由于上边提及了2个困扰，即便架构做无法得到位，开发人员也可以想办法去处理。业务组件少能够自己写，也可以找三方他人提前准备好的部件；经常复制编码都不是多大难题，开发人员可以利用在线编辑器的代码片段作用，或是多种方式去提高工作效率。
但一些略微特殊场景中，假如架构自身没有考虑到，那要求只有向架构让步，确实不是全部开发人员都是有这个能力详细阅读文章框架源码，然后进行二次开发订制作用。
说了那么多，可能很多人并不清楚究竟有哪些独特情景，在这里我举几个我遇到的：
你们可以比较一下如今在使用的框架能否达到这种场景中应用，也可以留言分享一些别的需求场景
1、导航条根据需求掩藏
导航条是一个必不可少的作用，特别是那种分两栏规划的导航栏（主导航栏 次导航），既然是分两栏导航栏，那么就会有次导航能不能隐藏情景，实际效果如下所示：
我的方法是由2个单独的配置项组合使用，完成了这一情景，各是 转换主导航栏时跳转到次导航里第一个频道路由器 和 次导航只有一个频道时隐藏 。
2、标签页合拼
标签页的实现是由路由器转换来完成的，每浏览一个路由器也会增加一个标签页。
不过有些情景必须对标签页开展合拼，例如不断从搜索结果页开启不一样条目地编写页，而且每个编写页的路由器不一样，因此相匹配还会形成好几个标签页，这时候我希望你能把所有编写页的标签页合拼成一个，实际效果如下所示：
既然是编写页合拼的画面，这也会出现搜索结果页和编写页合拼的画面，例如同一个控制模块下，不论是搜索结果页，或是编写页，或者其它同属该控制模块下页面，都希望合拼成一个标签页，实际效果如下所示：
这方面我的方法是提供了一个合拼规矩的配置项，默认设置不合拼，同时支持 依据路由器name开展合拼 和 依据activeMenu开展合拼 两根合拼标准，分别对应了以上2个情景，实际配备可参考文本文档详细介绍。
3、网页页面根据需求缓存文件
充分了解这样的场景前，大家需先明白什么页面缓存，便是当客户离去当前页后，再回到该网页页面，必须还原离去时的全部情况，这便是页面缓存。
页面缓存是一个常见的情景，一部分架构也提供了适用，但根据需求缓存文件，也就是按照离去并浏览目标页面，确定是否必须对当页开展缓存文件，举例说明：
假定 A 界面的缓存文件原则是，如果离开并浏览 B 网页页面则开展缓存文件，浏览别的网页页面一般不缓存文件；或是仅有离去并浏览 B 网页页面不缓存文件，浏览别的网页页面则都要缓存文件。
假如是上边假定的那2个情景，依照绝大多数架构所提供的水平（则在路由配置里提供一个网页页面是不是打开缓存文件设置项），就真不一定能满足，由于页面缓存会提供了二种情况，即自始至终缓存文件和一直不缓存文件。
而我的方法是各自带来了 cache 和 noCache 2个设定项，开发人员能够对 cache 设定 true/false 值以适应网页页面自始至终缓存文件或一直不缓存文件的画面，也能设路由器的name，完成精细化管理缓存文件操纵，或是拿上边2个情景举例说明，就能轻松配备成：
// A 网页页面离去并浏览 B 网页页面则开展缓存文件，浏览别的网页页面一般不缓存文件
cache: 'b-route-name' // B网页页面路由器name
// A 网页页面仅有离去并浏览 B 网页页面不缓存文件，浏览别的网页页面则都要缓存文件
cache: true,
noCache: 'b-route-name' // B网页页面路由器name
更多细节可参考文本文档详细介绍。
架构自身给予API少，可扩展性差
这一困扰的主要原因其实就是上一个困扰所造成的，由于水平少，所以能够显现出的结构方式也不多，所以能够所提供的 API 当然就少了。
在这里我便详细介绍好多个简单 API ，你们可以点浏览连接看预期效果：
1、主导航栏转换
import useMenu from '@/utils/composables/useMenu'
const { switchTo } = useMenu()
switchTo(index)
浏览
2、主页面刷新
import useMainPage from '@/utils/composables/useMainPage'
const { reload } = useMainPage()
reload()
浏览
3、主界面更大化
import useMainPage from '@/utils/composables/useMainPage'
const { maximize } = useMainPage()
// status: true / false
maximize(status)
浏览
4、动态性文章标题
有时，我们应该在某一个网页页面表明自定文章的标题，而非 meta.title 字段名，例如在编写客户页面，表明用户状态的名字。
import useSettingsStore from '@/store/modules/settings'
const settingsStore = useSettingsStore()
onMounted(() => {
settingsStore.setTitle('检测文章标题')
})
浏览
5、标签页有关
带来了开启、关掉、检测等 API 。
浏览
末尾
说到这里，想扯点有意思的话。
今年某一天，我忽然对“程序员转行，比较适合转产品运营”这话有了更多归属感。但在程序猿这一类别里，我觉得前端工程师就是其中尤其适宜转产品经理的。
因为大多数顾客没有人在乎你用什么技术，他们只是看好“表面”，像页面是不是漂亮，实际操作是否可行，动画特效是不是顺畅，而前端工程师绝大多数日常工作中内容是在与这种相处。当接触到了足够多项目需求，就会越挖掘客户想要的是什么，就可以在下一个项目需求里迅速找到在其中的痛点或是不合理地区，同时提供一个相对成熟解决方案，这同时也是一个产品运营所应当掌握的技能与经验。
就好比我写这一款智能管理系统架构，这一年我不甘于堆积新特性，反而是在这个基础上思索如何更强去服务项目使用我这一套框架的开发人员，不但达到用户的需求，还需要让她们用到舒服，如同 Fantastic-admin 官网首页的标语——“开箱即用，给予舒服开发设计感受”。
感谢各位阅读文章到这儿，期待原文中我愚见能给大家带来了一些启迪。