一个组件库通常有数十个组件，随着版本迭代组件数量还可能进一步增加。组件库文件的体积也随之膨胀，动辄几百KB。而我们的业务项目中，有可能只用到了这个组件库的少数几个组件，这时把整个组件库打包进去，非但没有必要，还会徒增项目构建文件的体积，这与应用性能优化的方向是背道而驰的。因此，组件库有必要提供一种更灵活的组件引用方式，允许应用只引用指定的组件。事实上，主流的组件库基本都具备“按需加载组件”功能。

 

最简单的“按需加载组件”实现方式，就是在应用中直接引用所需组件的源文件，在应用的构建工具中跟应用一起构建。说它简单，是因为这种方式几乎不需要组件库做什么工作，应用直接引用组件源码，并不需要经过组件库的构建过程。

 

这种方式的局限性也大都与“组件未经组件库构建”有关。在应用中构建这些组件，就意味着应用的构建工具必须要具备构建这些组件的能力。比如需要有编译Vue模板、编译ES6+语法、编译Scss/Less语法、支持postcss等的能力，如果说上面这些功能很基础，大多数应用的构建工具都能支持，那么组件可能还有一些不太常见或者组件库特有的功能，比如处理SVG、定制主题、国际化等等，通常应用构建工具不具备或者依赖于组件库配置文件，这就给直接在用户的应用中编译组件源码带来了困难。另一方面，未经构建的组件模块化接口单一，无法直接在其他模块化场景和非模块化场景使用。还有，如果组件库支持直接引用组件源码，则需要把所有组件源码随NPM包一起发布，可能会导致npm包过大，看起来并不是一个好主意。

 

好吧，我们换个思路，不直接引用组件源码，而是让组件库对这些用户指定的组件（而非全部组件）进行构建，生成一个自定义版本的组件库给用户应用使用。这就需要组件库与用户进行交互，收集用户所需要的组件信息，然后将指定组件编译成一个自定义版本的库文件。这种自定义构建方案常见的情况有两种，一种是通过网页收集信息，在服务端进行构建。遥想当年jQuery时代，jQuery-UI库提供的自定义构建下载方式[1]，让用户在线选择所需组件，然后在服务端进行编译，完成后提供给用户下载（当然，服务端也可能存在已经提前编译完的各种组合的构建包）。那个时代已然远去，如今下载安装组件库“政治正确”的姿势是通过npm/Yarn。

 

另一种方案是通过命令行界面（CLI）收集信息并在客户端构建。比如jQuery的“不同父异母”的小兄弟Zepto.js，官方标准包里只包含部分模块，如果需要增加或移除模块就需要进行自定义构建了：在Zepto.js项目目录下安装依赖，在MODULES中指定需要的模块，然后执行npm run-script dist进行构建，完事儿后dist目录下zepto.js和zepto.min.js就是自定义构建出来的包，拿到项目里使用即可。这种方式节约服务器资源，甚至不需要自己的服务器。