本文记录了我是如何搭建后台管理系统的，以及我的一些反思和心得。

我们公司希望做一个更符合业务需求的后台管理系统，因此需要我重新搭建一个新后台出来。以下是对我根据自己搭建新后台的一些记录。

首先，我确定了项目要使用的技术栈：vue+vuex+vue-router+elementUI。 然后我利用脚手架搭建了一个项目出来。 这个后台管理系统我是直接参考了后台前端解决方案，并最终在使用了该开发者提供的另外一个极简的 vue admin 管理后台。因为我们这个后台不需要那么多功能，我打算在这个模板的基础上按照需求添加功能。

但是，我也没有直接使用这个极简模板，主要原因是我觉得它的目录结构以及部分规范不符合我的希望，因此最终我是脚手架搭建了一个项目，并按照极简模板的实现按照新的目录规范移植了过来。

以下是我刚开始时定义的目录结构：

到这里，其实这后台的框架就大致搭建好了。

接着我制定了项目开发约定的风格 这里我是参考了单文件组件文件的大小写-强烈推荐

组件可以存放在两个地方：/src/base /src/components 以及 views 内（仅限非公共的业务组件） components文件夹内所有的Component文件夹都是以大写开头 (PascalCase)，同时组件以 index.vue 命名 部分视图使用的非公共组件，可以直接放在对应视图文件夹内，文件同样要以大写开头，以便与视图文件分开

视图文件统一放在 views 中，所有视图文件统一使用横线连接 (kebab-case)，代表路由的文件夹也是使用同样的规则。某些情况下，命名允许使用数字。 视图是和路由对应的，为了避免 views 文件夹里视图文件过多，一个模块（或者说对应后台的一个一级菜单，对应路由的话就是一级路由）必须起一个文件夹，二级路由后可以视情况决定是否要保持和路由一致。

所有的.js文件都遵循横线连接 (kebab-case)。

例子：

API 需要和请求的使用位置的目录结构一一对应，如果已知请求被多个地方使用，可以在/src/api 文件夹内新建一个 public 文件夹放置这些通用的请求

在大致定下了目录和风格后，我开始尝试结合业务与开发需求，调整一下webpack的配置。

开始的时候，我想到了这后台可能要用于管理员后台、代理商后台等，这个是我们的项目主管要求的，理由是这样一个后台比较好维护。因此我一开始的思路是这3个项目整体结构是一样的，登录页面是不同的，每个后台的页面可能也是不同的，但是它的底层配置是同一套的，同时组件必须懒加载，因为显然管理员后台是不需要加载代理商后台的代码的。 有了这个大致的想法，我就想到我想到了一种实现： 利用环境变量，来区分不同的后台，使用VUE_APP_USER_TYPE来标识。 然后编译代码时要用命令行控制环境变量，使用类似npm run serve:admin来传入不同的环境变量。 利用这个办法，我也许可以控制代码打包时只打包对应后台相关的代码。但这个我没有最终实践，因为后面发现3个后台的权限等实现不尽相同，拆开开发的话效率更高，所以放弃了这种3合一的想法。事实上，后台框架搭建好后，底层的变动是很小的，没有必要非要将3个后台合并在一起。

但是环境变量这个我其实还是用到了，因为这套代码要同时应用到不同的项目中，二者的区别不大，因此我还是用了环境变量来区分不同的项目，不过这两个项目的代码是一模一样的，所以不需要根据不同项目打包不同的代码。当然，这两个项目的环境变量不同，会导致个别变量和逻辑有一点不大的区别。

在原模版上进行开发，我发现进行代码调试异常痛苦，经过研究，发现是因为配置时，我采用的极简模版配置开发时的代码映射（SourceMaps）不是精确的行映射和列映射，这大概是该开发者希望提高速度而做的配置，但我觉得这反而影响了我开发定位问题调试的效率。我认为开发时调试是非常重要的，因此将其重新调整为’eval-source-map’，按照文档，它为开发提供了最优质的SourceMaps。

It yields the best quality SourceMaps for development.

相关的文档文档：Development

这个又是一个提高开发效率的配置，特别的不仅仅可以配置js的别名，还可以配置预处理器引入文件夹的别名。 这样引入特定文件夹样式时就方便多了

例如我希望打包后，生成的文件夹可以根据环境生成相应的文件夹，以下是例子