增量构建的可⾏性
Webpack 中的增量构建
在开启 devServer 时，当我们执⾏ webpack-dev-server 命令后，Webpack 会进⾏⼀次初始化的构建，构建完成后启动服务并进⼊到等待更新的状态。当本地⽂件有变更时，Webpack ⼏乎瞬间将变更的⽂件进⾏编译，并将编译后的代码内容推送到浏览器端。这就称为“增量构建”。
增量构建的影响因素
-
watch 配置
-
cache 配置
增量构建的实现原理
-
watch 配置的作⽤
在 watch 模式下，构建完成后并不⾃动退出，因此构建上下⽂的对象（包括前⼀次构建后的缓存数据对象）都可以保留在内存中，并在 rebuild 时重复使⽤。 -
cache 配置的作⽤
cache 配置的源码逻辑主要涉及两个⽂件：CachePlugin.js 和 Compilation.js。
CachePlugin.js 的核⼼作⽤是将该插件实例的 cache 属性传⼊ compilation 实例中。
在 Compilation.js 中，运⽤ cache 的地⽅有两处：- 在编译阶段添加模块时，若命中缓存 module，则直接跳过该模块的编译过程（与 cacheloader 等作⽤于加载器的缓存不同，此处的缓存可直接跳过 Webpack 内置的编译阶段）。
- 在创建 Chunk 产物代码阶段，若命中缓存 Chunk，则直接跳过该 Chunk 的产物代码⽣成过程。
从内部原理的⻆度分析，watch 的作⽤是保留进程，使得初次构建后的数据对象能够在再次构建时复⽤。⽽ cache 的作⽤则体现在构建过程中，在添加模块与⽣成产物代码时可以利⽤ cache 对象进⾏相应阶段结果数据的读写。显然，这种基于内存的缓存⽅式⽆法在⽣产环境下⼴泛使⽤。
⽣产环境下使⽤增量构建的阻碍
增量构建之所以快是因为将构建所需的数据（项⽬⽂件、node_modules 中的⽂件数据、历史构建后的缓存数据等）都保留在内存中。在 watch 模式下保留着构建使⽤的 Node 进程，使得下⼀次构建时可以直接读取内存中的数据。
⽽⽣产环境下的构建通常在集成部署系统中进⾏。对于管理多项⽬的构建系统⽽⾔，构建过程是任务式的：任务结束后即结束进程并回收系统资源。
要想在⽣产环境下提升构建速度，⾸要条件是将缓存写⼊到⽂件系统中。只有将⽂件系统中的缓存数据持久化，才能脱离对保持进程的依赖，你只需要在每次构建时将缓存数据读取到内存中进⾏处理即可。Webpack 5 中正式⽀持基于⽂件系统的持久化缓存（Persistent Cache）。
