管理后台十分适合量产，一般的后台构成元素都一样，同质化程度很高，在完成了一个后台项目后要再开发一个，基本上只需要复制粘贴然后改业务逻辑。
单纯地复制粘贴会引发一些小问题，在后台数量多的时候尤其突出，长远来看，需要一套完善的管理方案对这些后台进行管理，以避免如下问题：
- 新建一个后台，需要复制一次原型，而依赖文件是个无底洞，无论复制还是重新下载都会浪费不少时间。
- 架构文件更新不同步，一个后台一份代码，无法管理差异，同步修改只能手动操作，误操作的风险很大。
- 架构文件与业务文件混合管理，无法有效分离关注点，业务操作不够清晰，同样有误操作的风险。
最严重的自然是依赖黑洞，要解决的话需要项目的依赖目录唯一，以这个为出发点不难构思出整个管理模式，即通过脚本自动化管理项目业务文件，统一维护项目核心文件，不同后台是不同项目，同时也是一个项目，开发与构建对象取决于执行脚本时传入的参数。
立身于巨人之肩，瞬息可逾千里。Node.js 支持直接运行脚本，Vite 支持以函数的方式启动开发与服务，稍微处理就可以通过 Node.js 启动所需要的服务了，方案如下：
- 手动编写脚本分析数据并启动相关服务，为方便参数传递，不使用 npm 管理脚本。
- 核心文件放
src目录，业务文件放src_${name}目录，使核心文件更新不需同步，只需要重新构建发布对应后台。 - 尽可能简化业务目录，尽可能配置化核心功能，同时要考虑任何可能的扩展方向，尽可能地提升开发体验。
最后有一点需要特别注意：核心功能是在后台中生效的，任何修改都需要考虑是否有兼容性问题。
接口若有差异自然是无法运行的，接口相关配置必定要修改，在此开源前端部分，仅是为了展示一种项目的可能性：展示地址。
- 复制业务目录，修改相关信息，比如目录名、项目配置、路由配置。
node serve ${name}启动开发服务。- 根据路由配置修改业务文件目录，并编写其中的业务逻辑。
node build ${name}启动构建服务。node build ${name} true将在构建完毕时把源码添加到压缩文件。${name}也可作src_${name}，命令会自动判断处理src_前缀。
不同项目所依赖的插件不一样，但项目管理上没办法针对具体项目分割依赖配置，若是用黑科技进行分割，又难免会出现各项目基础库出现差异的情况，而这正是最开始希望解决的痛点。
所以当一个项目需要某个依赖的时候会进行安装，然后在依赖信息中记上，直到有一天没有一个项目会用到了，再将其手动移除，也有可能一直没有注意，让依赖信息越发臃肿。
目前来说还没发现好的方案去解决这种问题，通常建议是在业务目录中以文件的形式记录相关特殊依赖信息，手动维护一个依赖记录，而基础库的依赖信息通常是只使用最新的。
目前非必要依赖只有两个，分别是 echarts 与 qrcode，如果不需要，也可以在自己的项目中移除。
.
├─ src，项目基础文件内容，私有文件内容建议与其子目录结构一致
│ ├─ components，全局组件目录，具体说明在目录内的 README.md 中
│ ├─ image，全局图片目录
│ ├─ pages，框架页面、登录页面、系统首页（默认跳至管理页面）
│ ├─ style，全局样式
│ ├─ tools，全局工具函数，包括项目初始化与路由初始化等内容，具体说明在目录内的 README.md 中
│ └─ index.js，生成 vite.config.js 的逻辑
│
├─ src_${name}，具体后台的私有文件
│ ├─ config，后台配置内容，具体说明在目录内的 README.md 中
│ │ ├─ config.json，后台基础配置
│ │ ├─ language.js，私有语言包配置
│ │ ├─ route.js，路由与菜单配置
│ │ └─ store.js，后台数据库配置
│ │
│ ├─ pages，后台页面内容，具体使用方法可以参考其中的代码
│ │ └─ index，首页，当此目录缺失时会使用基础目录中的首页，404 会重定向至此
│ └─ index.js，后台初始化方法，可以在这里注册一些全局方法或组件
│
├─ build.js，启动构建
├─ serve.js，启动开发服务器
└─ index.html，项目入口模板