随着业务的不断累积，目前我们 ToC 端主要项目，除去 node_modules， build 配置文件，dist 静态资源文件的代码量为 137521 行，后台管理系统下各个子应用代码，除去依赖等文件的总行数也达到 100万 多一点。

代码量意味不了什么，只能证明模块很多，但相同两个项目，在运行时性能相同情况下，你的 10 万行代码能容纳并维护 150 个模块，并且开发顺畅，我的项目中 10 万行代码却只能容纳 100 个模块，添加功能也好，维护起来也较为繁琐，这就很值得思考。

本文会在主要描述以 Vue 技术栈为技术主体，ToC 端项目业务主体，在构建过程中，遇到或者总结的点（也会提及一些 ToB 项目的场景），可能并不适合你的业务场景（仅供参考），我会尽可能多的描述问题与其中的思考，最大可能的帮助到需要的同学，也辛苦开发者发现问题或者不合理/不正确的地方及时向我反馈，会尽快修改，欢迎有更好的实现方式来 pr。

可以参考蚂蚁金服数据体验技术团队编写的文章：

本文并不是基于上面文章写的，不过当时在看到他们文章之后觉得有相似的地方，相较于这篇文章，本文可能会枯燥些，会有大量代码，同学可以直接用上仓库看。

首先要思考我们的项目最终的构建主体是单页面，还是多页面，还是单页 + 多页，通过他们的优缺点来分析：

我们首先根据业务所需，来最终确定构建主体，而我们选择了体验至上的 SPA，并选用 Vue 技术栈。

其实我们看开源的绝大部分项目中，目录结构都会差不太多，我们可以综合一下来个通用的 src 目录：

components 中我们会存放 UI 组件库中的那些常见通用组件了，在项目中直接通过设置别名来使用，如果其他项目需要使用，就发到 npm 上。

如果想最终编译成 es5，直接在 html 中使用或者部署 CDN 上，在 build 配置简单的打包逻辑，搭配着 package.json 构建 UI组件 的自动化打包发布，最终部署 dist 下的内容，并发布到 npm 上即可。

而我们也可直接使用 es6 的代码：

假设我们发布的 npm 包叫 bm-ui，并且下载到了本地 npm i bm-ui -S:

修改项目的最外层打包配置，在 rules 里 babel-loader 或 happypack 中添加 include，node_modules/bm-ui：

然后搭配着 babel-plugin-import 直接在项目中使用即可：

同时有多个组件库的话，又或者有同学专门进行组件开发的话，把 components 内部细分一下，多一个文件分层。

你的打包配置文件可以放在 components 下，进行统一打包，当然如果要开源出去还是放在对应库下。

这个点其实会是项目中经常被忽略的，或者说很少聚合到一起，但同时我认为是整个项目中的重要之一，后续会有例子说道。

我们在 config/index.js 可能会有如下配置：

可以看出这里汇集了项目中所有用到的配置，下面我们在 plugins 中实例化插件，注入对应配置，目录如下:

这里先举出两个例子，看我们是如何注入配置，拦截器并实例化的

实例化 router：

实例化 axios：

我们在 main.js 注入插件：

axios 实例我们并没有直接引用，相信你也猜到他是通过 inject 插件引用的，我们看下 inject：

这里可以挂载你想在业务中( vue 实例中)便捷访问的 api，除了 $ajax 之外，api 和 const 两个插件是我们服务层中主要的功能，后续会介绍，这样我们插件流程大致运转起来，下面写对应拦截器的方法。

在ajax 拦截器中(config/interceptors/axios.js)：

定义路由拦截器(config/interceptors/router.js)：

最后在入口文件(config/interceptors/index.js)中引入并暴露出来即可:

请求拦截这里代码都很简单，对于 responseSuccessFunc 中 switch default 逻辑做下简单说明：

这里也可以把弹窗状态放入 Store 中，按团队喜好，我们习惯把公共的涉及视图逻辑的公共状态在这里注册，和业务区分开来。

对比下处理前后在业务中的发送请求的代码：

拦截器处理前：

拦截器处理后：

在应对项目开发过程中需求的不可预见性时，让我们能处理的更快更好

到这里很多同学会觉得，就这么简单的引入判断，可有可无， 就如我们最近做的一个需求来说，我们 ToC 端项目之前一直是在微信公众号中打开的，而我们需要在小程序中通过 webview 打开大部分流程，而我们也没有时间，没有空间在小程序中重写近 100 + 的页面流程，这是我们开发之初并没有想到的。这时候必须把项目兼容到小程序端，在兼容过程中可能需要解决以下问题：

可以看出，稍微不慎，会影响公众号现有逻辑。

最终用最少的代码，最快的时间完美上线，丝毫没影响到现有 toC 端业务，而且这样把所有兼容逻辑绝大部分聚合到了一起，方便二次拓展和修改。

虽然这只是根据自身业务结合来说明，可能没什么说服力，不过不难看出全局配置/拦截器 虽然代码不多，但却是整个项目的核心之一，我们可以在里面做更多 awesome 的事情。

directives 里面没什么可说的，不过很多难题都可以通过他来解决，要时刻记住，我们可以再指令里面操作虚拟 DOM。

而我们根据自己的业务性质，最终根据业务流程来拆分配置：

最终通过 index.js 暴露出去给 plugins/router 实例使用，这里的拆分配置有两个注意的地方：

文章开头说到单页面静态资源过大，首次打开/每次版本升级后都会较慢，可以用懒加载来拆分静态资源，减少白屏时间，但开头也说到懒加载也有待商榷的地方：

这就需要我们根据项目情况在空间和时间上做一些权衡。

以下几点可以作为简单的参考：

打包出来的 main.js 的大小，绝大部分都是在路由中引入的并注册的视图组件。

服务层作为项目中的另一个核心之一，“自古以来”都是大家比较关心的地方。

不知道你是否看到过如下组织代码方式：

在 service.js 中写入编写数据来源

简单分析：

我相信②在绝大多数项目中都能看到。

那么我们的目的就很明显了，解决冗余，方便使用，我们把枚举和请求接口的方法，通过插件，挂载到一个大对象上，注入 Vue 原型，方面业务使用即可。

首先抽离请求接口模型，可按照领域模型抽离 (service/api/index.js):

定制下需要的几个功能：

定制好功能，开始编写简单的 plugins/api.js 插件：

挂载到 Vue 原型上，上文有说到，通过 plugins/inject.js

这样我们可以在业务中愉快的使用业务层代码：

即使在业务之外也可以使用：

当然对于运行效率要求高的项目中，避免内存使用率过大，我们需要改造 API，用解构的方式引入使用，最终利用 webpack 的 tree-shaking 减少打包体积。几个简单的思路

一般来说，多人协作时候大家都可以先看 api 是否有对应接口，当业务量上来的时候，也肯定会有人出现找不到，或者找起来比较费劲，这时候我们完全可以在 请求拦截器中，把当前请求的 url 和 api 中的请求做下判断，如果有重复接口请求路径，则提醒开发者已经配置相关请求，根据情况是否进行二次配置即可。

最终我们可以拓展 Service 层的各个功能：

基础

拓展

const，localStorage，monitor 和 beacon 根据业务自行拓展暴露给业务使用即可，思想也是一样的，下面着重说下 store(Vuex)。

插一句：如果看到这里没感觉不妥的话，想想上面 plugins/api.js 有没有用单例模式？该不该用？

Vuex 源码分析可以看我之前写的文章。

答案是否定的，就算你的项目达到 10 万行代码，那也并不意味着你必须使用 Vuex，应该由业务场景决定。

当然对于这类项目，vuex 或许不是最好的选择，有兴趣的同学可以学习下 rxjs。

全局共享状态不多，但是难免在某个模块中会有复杂度较高的功能(客服系统，实时聊天，多人协作功能等)，这时候如果为了项目的可管理性，我们也在 store 中进行管理，随着项目的迭代我们不难遇到这样的情况：

先梳理我们的目标：

我们借助 Vuex 提供的 registerModule 和 unregisterModule 一并解决这些问题，我们在 service/store 中放入全局共享的状态：

一般这类项目全局状态不多，如果多了拆分 module 即可。

编写插件生成 store 实例：

对一个需要状态管理页面或者模块进行分层：

module 中直接包含了 getters，mutations，state，我们在 store/index.js 中做文章：

最终在 index.vue 中引入使用， 在页面跳转之前注册这些状态和管理状态的规则，在路由离开之前，先卸载这些状态和管理状态的规则：

当然如果你的状态要共享到全局，就不执行 uninstall。

这样就解决了开头的三个问题，不同开发者在开发页面的时候，可以根据页面特性，渐进增强的选择某种开发形式。

这里简单列举下其他方面，需要自行根据项目深入和使用。

这里网上已经有很多优化方法：dll，happypack，多线程打包等，但随着项目的代码量级，每次 dev 保存的时候编译的速度也是会愈来愈慢的，而一过慢的时候我们就不得不进行拆分，这是肯定的，而在拆分之前尽可能容纳更多的可维护的代码，有几个可以尝试和规避的点：

MPA 应用中样式冗余过大，%placeholder 也会给你带来帮助。

很多大公司都有自己的 mock 平台，当前后端定好接口格式，放入生成对应 mock api，如果没有 mock 平台，那就找相对好用的工具如 json-server 等。

请强制使用 eslint，挂在 git 的钩子上。定期 diff 代码，定期培训等。

非常建议用 TS 编写项目，可能写 .vue 有些别扭，这样前端的大部分错误在编译时解决，同时也能提高浏览器运行时效率，可能减少 re-optimize 阶段时间等。

这也是项目非常重要的一点，如果你的项目还未使用一些测试工具，请尽快接入，这里不过多赘述。

当项目到达到一定业务量级时，由于项目中的模块过多，新同学维护成本，开发成本都会直线上升，不得不拆分项目，后续会分享出来我们 ToB 项目在拆分系统中的简单实践。

时下有各种成熟的方案，这里只是一个简单的构建分享，里面依赖的版本都是我们稳定下来的版本，需要根据自己实际情况进行升级。

项目底层构建往往会成为前端忽略的地方，我们既要从一个大局观来看待一个项目或者整条业务线，又要对每一行代码精益求精，对开发体验不断优化，慢慢累积后才能更好的应对未知的变化。