接上篇【webpack 模块加载原理及打包文件分析 (一)】
入口文件拆包(如拆分 runtime)的情况
webpack 的默认处理机制是入口文件及它的同步依赖(包括第三方包)打包成一个 chunk，里边还包含 runtime (自执行的 webpackBootstrap 函数)，然后每个异步引入的模块单独输出一个 chunk。
关于异步模块：1. 如果有入口 chunk 中同样的同步依赖，最终输出的异步 chunk 中不会包含这个依赖，而是直接引用入口中的这个模块；2. 入口中没有的同步依赖会被打包进异步 chunk；3. 它的每个异步依赖或者同步的第三方包，会被单独打包成一个 chunk。
入口 chunk 即包含我们入口模块及其依赖的 js，是运行时最先(初始)加载的 js。实际项目中，为了性能优化减少单个 js 的体积通常都会将入口 chunk 分割成几个，同时将几乎每次打包都会变化的 runtime 单独抽出，以保证部分 chunk 稳定的缓存。
// webpack 配置
module.exports = {
optimization: {
runtimeChunk: { // 抽出 bootstrap 运行代码
name: 'runtime',
},
splitChunks: { // 优化分包，默认会抽出第三方包和公共模块
chunks: 'all',
}
}
}
通过配置optimization.runtimeChunk将 runtime 抽出，原本的 webpackBootstrap IIFE函数不再像上面一样包含在 index.js 中，而单独成一个runtime.js。
打包结果中的 Entrypoint 会告知我们入口文件被拆分成哪些 chunk，以及这几个js的加载顺序(从前到后)。
可以通过配置 webpack-dev-server ，将项目运行在浏览器上来观察运行过程。
前一篇我们讲过单个入口 chunk (上篇的index.js) 执行逻辑，简单地说就是：将包含所有同步模块(包括第三方包)的对象作为参数传入 bootstrap 执行，然后异步 chunk (上篇的0.js) 在用到时发起JSONP请求加载并执行。
而现在不仅bootstrap中会多出不少代码，运行项目执行的流程也会有所不同：
首先都会多生成一个变量deferredModules和一个checkDeferredModules函数。
重点拎出 ④deferredModules：用于缓存运行当前 webapp 需要的入口 module ID 以及 依赖的同步 chunk ID（截图中 Entrypoint 指明了入口文件需后于 runtime 和 vendors~index 执行），这个很好理解，我们自己写的代码基本上都需要第三方包先加载成功后才能运行。
而checkDeferredModules方法就是在deferredModules有数据的基础上，查看运行入口模块之前有无其他必须先运行的 chunk，再确认这些 js 已经执行完毕再开始同步加载入口模块的代码。
其余bootstrap代码简化如下，只留本次需要用到的，略掉上篇讲过的异步部分：
// 加载异步 chunk 或其他被拆分的同步 chunk 后的回调函数
// 该方法会记录管理 chunk 的加载状态，并将 moreModules 装载到 modules 中
// 如果是异步 chunk 会把它的 promise resolve 出去，也就是让`_webpack_require__.e().then` 里的回调得以继续执行
function webpackJsonpCallback(data) {
var chunkIds = data[0]; // chunkID 数组
var moreModules = data[1]; // chunk 里所有的模块对象
var executeModules = data[2]; // 在执行`index.js`时即入口模块`chunk`才会有的第三个参数 [["./src/a.js","runtime","vendors~index"]]
var moduleId, chunkId, i = 0;
for(;i < chunkIds.length; i++) {
installedChunks[chunkId] = 0; // 把这个 chunk 标记为已加载
}
// 遍历 moreModules，把 chunk 所有模块内容深拷贝给 modules，也就是 webpackBootstrap 的参数指向的地址
// modules 为 webpackBootstrap 的闭包变量，作用域内的函数自然可以获取
for(moduleId in moreModules) {
if(Object.prototype.hasOwnProperty.call(moreModules, moduleId)) {
modules[moduleId] = moreModules[moduleId];
}
}
// 执行 window["webpackJsonp"] 原生的.push，那么 webpackJsonp 数组此时就有了这个 chunk 的所有信息
if(parentJsonpFunction) parentJsonpFunction(data);
// add entry modules from loaded chunk to deferred list
// 把 executeModules 的所有项添加到 deferredModules 数组，
// 每一是由入口模块ID 和它依赖的 chunkID (即需要在入口模块之前执行的 chunk) 组成的数组，如["./src/a.js","runtime","vendors~index"]
deferredModules.push.apply(deferredModules, executeModules || []);
// run deferred modules when all chunks ready
// 运行延迟的同步模块
return checkDeferredModules();
}
function checkDeferredModules() {
var result;
for(var i = 0; i < deferredModules.length; i++) { // 遍历二维数组
var deferredModule = deferredModules[i]; // 如 ["./src/a.js","runtime","vendors~index"]
var fulfilled = true;
for(var j = 1; j < deferredModule.length; j++) {
var depId = deferredModule[j]; // 入口模块ID 或 它依赖的 chunk ID
// 确认入口模块依赖的每一个 chunk 都加载执行了
if(installedChunks[depId] !== 0) fulfilled = false;
}
if(fulfilled) {
// i 为 -1, 即删除最后一项，清空 deferredModules 数组
deferredModules.splice(i--, 1);
// deferredModule[0] 为第一项，即入口模块的ID'./src/a.js"'，实际运行时这个 ID 是 0
result = __webpack_require__(__webpack_require__.s = deferredModule[0]);
}
}
return result;
}
var installedChunks = {
"runtime": 0, // 初始加载的 chunk
// "index": 0 // 如没抽 runtime
};
// 缓存延迟加载入口模块和 chunk
// 数组的每一项是 一个入口模块ID 及 它依赖的 chunk ID 组成的数组
// 二维设计是为了多入口模式
var deferredModules = [];
// 全局变量 window["webpackJsonp"]，存储动态导入/入口拆分出的同步 chunks
var jsonpArray = window["webpackJsonp"] = window["webpackJsonp"] || [];
// 定义 jsonpArray 的原生 push 方法
var oldJsonpFunction = jsonpArray.push.bind(jsonpArray);
// 重写 window["webpackJsonp"].push 方法为 webpackJsonpCallback 函数
jsonpArray.push = webpackJsonpCallback;
// 把 jsonpArray 还原成普通数组
jsonpArray = jsonpArray.slice();
// jsonpArray 不为空时为每项循环执行 webpackJsonpCallback
for(var i = 0; i < jsonpArray.length; i++) webpackJsonpCallback(jsonpArray[i]);
// jsonpArray 原生 push 方法赋给 parentJsonpFunction
var parentJsonpFunction = oldJsonpFunction;
// 未抽出 runtime 且入口分包的情况
// deferredModules.push(["./src/a.js","vendors~index"]);
// return checkDeferredModules();
// run deferred modules from other chunks
// 检查有无延迟同步块并去运行
checkDeferredModules();
如果runtime被抽出，webpackBootstrap 传入的参数为一个空数组。原本的index.js中 push 的参数(Array)会有第三项值，结构是一个[[入口模块 ID, runtime, 第三方包chunk ID(如果有的话)]]的二维数组：本例：[["./src/a.js","runtime","vendors~index"]]，简化如下：
// dist/index.js
(window["webpackJsonp"] = window["webpackJsonp"] || []).push([["index"],{
"./src/a.js": (function() {}),
"./src/b.js": (function() { }),
"./src/d.js":(function() {})
},[["./src/a.js", "runtime", "vendors~index"]]]);
现在我们根据打包文件的执行顺序来捋一捋新增的代码做了什么：
-
runtime.js：传入的参数为空数组，window["webpackJsonp"]、deferredModules也是空的，除了重写window["webpackJsonp"].push为webpackJsonpCallback函数、做了一些变量赋值就没有别的了。 - 然后执行入口模块分出的
vendors~index.js，window["webpackJsonp"].push也就webpackJsonpCallback，把这个 chunk 以"vendors~index": 0的形式存储到installedChunks对象，以表示这个 chunk 已加载。跟着把 chunk 所有模块内容深拷贝给 modules。
再执行webpackJsonp原生的push，把vendors~indexchunk 的所有信息存入window["webpackJsonp"]数组，信息为一个包含两项内容的数组：[["vendors~index"], 包含文件中所有 modules 的对象]。 - 再依法炮制
index.js，"index": 0存储到installedChunks，把 chunk 所有模块内容深拷贝给 modules。再把chunk 的所有信息存入全局"webpackJsonp"，信息为包含三项内容的数组：[["index"], 包含入口模块和它的同步依赖信息的 modules 对象，[["./src/a.js","runtime","vendors~index"]]]。
跟着把这第三个参数添加到deferredModules数组，再通过checkDeferredModules遍历这个数组，确认入口模块的同步依赖都已经加载后，用__webpack_require__去执行入口模块。(注：开发环境模块 ID 是源文件路径，生产环境则是一些数字或字符串标识，例如0) - 此时所有同步模块的数据都以 { 模块ID: 模块函数, ... } 的形式存储在 webpackBootstrap 的
modules闭包变量中，因此通过执行入口模块(a.js)的函数，连接其他同步模块时都可以通过 module ID 获取并执行它们的模块函数。如果是这些模块已经被执行过，会被存在installedModules里，需要引用时直接获取模块导出值(exports)即可。(详见上一篇的__webpack_require__部分，执行的模块函数都是通过modules[moduleId]拿到的) - 之后异步模块的部分，上篇已讲过不再赘述。
若 script 标签加上 async 属性
入口拆包后的加载机制其实很简单，一言蔽之就是在加载入口模块之前把同步依赖的 chunk 都先执行了，然后执行入口 module 代码。
webpackBootstrap 代码设计得很巧妙，拆包后的同步 chunk 即使不是按照本该的顺序执行，项目也能正常运行。
比如先于runtime运行了vendors~index，那么window["webpackJsonp"]就已经包含了这个 chunk 的信息，然后再执行 bootstrap，改写 webpackJsonp 的原生 push 为 webpackJsonpCallback。
为webpackJsonp数组每一项 (chunk) 执行webpackJsonpCallback。
于是每次加载完当前 chunk 都会调用checkDeferredModules判断是否它是否有依赖的 chunk，有的话保证这些 chunk 加载完毕后就会去执行入口 module。
借用一张大神的图大致说明以上两种情况的流程：
⚠️：标注 ①、②、③、④ 的四个变量需要重点理解，对理解 webpack 加载逻辑很有帮助。
参考文章：
Webpack 是怎样运行的?（一）
Webpack 是怎样运行的?（二）
聊聊 webpack 异步加载（一）：webpack 如何加载拆包后的代码
webpack是如何实现动态导入的
