深入理解webpack打包机制(7)

大致分为三种情况，(已经加载过，正在加载中以及从未加载过)

1. 已经加载过该 chunk 文件，那就不用再重新加载该 chunk 了，直接执行回调函数即可，可以理解为假如页面有两种操作需要加载加载异步脚本，但是两个脚本都依赖于公共模块，那么第二次加载的时候发现之前第一次操作已经加载过了该 chunk，则不用再去获取异步脚本了，因为该公共模块已经被执行过了。
2. 从未加载过，则动态地去插入 script 脚本去请求 js 文件，这也就为什么取名 webpackJsonpCallback，因为跟 jsonp 的思想很类似，所以这种异步加载脚本在做脚本错误监控时经常出现 Script error，具体原因可以查看我之前写的文章：
3. 正在加载中代表该 chunk 文件已经在加载中了，比如说点击按钮触发异步脚本，用户点太快了，连点两次就可能出现这种情况，此时将回调函数放入 installedChunks。

通过 utilC 生成的 chunk 来进行讲解：

pageB需要异步加载这个chunk:

当 pageB 进行某种操作需要加载 utilC 时就会执行__webpack_require__.e(0,callback), 0，代表需要加载的模块 chunkId(utilC)，异步加载 utilC 并将 callback 添加到 installedChunks[0] 中，然后当 utilC 的 chunk 文件加载完毕后，chunkIds 包含 1，发现 installedChunks[0] 是个数组，里面还有之前还未执行的 callback 函数

既然这样，那我就将我自己带来的模块先放到 modules 中，然后再统一执行之前未执行完的 callbacks 函数，这里指的是存放于 installedChunks[1] 中的回调函数 (可能存在多个)，这也就是说明这里的先后顺序：

webpack2 中会默认加载 OccurrenceOrderPlugin 这个插件，即你不用 plugins 中添加这个配置它也会默认执行，那它有什么用途呢？主要是在 webpack1 中 moduleId 的不确定性导致的，在 webpack1 中 moduleId 取决于引入文件的顺序，这就会导致这个 moduleId 可能会时常发生变化,而 OccurrenceOrderPlugin 插件会按引入次数最多的模块进行排序，引入次数的模块的 moduleId 越小，比如说上面引用的 utilB 模块引用次数为 2(最多)，所以它的 moduleId 为 0。

最后说下在异步加载模块时， webpack2 是基于 Promise 的，所以说如果你要兼容低版本浏览器，需要引入Promise-polyfill，另外为引入请求添加了错误处理。

在 webpack1 的时候，如果由于网络原因当你加载脚本失败后，即使网络恢复了，你再次进行某种操作需要同个 chunk 时候都会无效，主要原因是失败之后没把installedChunks[chunkId] = undefined;导致之后不会再对该 chunk 文件发起异步请求。

而在 webpack2 中，当脚本请求超时了(2min)或者加载失败，会将 installedChunks[chunkId] 清空，当下次重新请求该 chunk 文件会重新加载，提高了页面的容错性

三、webpack2如何做到tree shaking?

什么是 tree shaking，即 webpack 在打包的过程中会将没用的代码进行清除(dead code)。一般 dead code 具有一下的特征：

1. 代码不会被执行，不可到达
2. 代码执行的结果不会被用到
3. 代码只会影响死变量（只写不读）

是不是很神奇，那么需要怎么做才能使 tree shaking 生效呢？

首先，模块引入要基于 ES6 模块机制，不再使用 commonjs 规范，因为 es6 模块的依赖关系是确定的，和运行时的状态无关，可以进行可靠的静态分析，然后清除没用的代码。而 commonjs 的依赖关系是要到运行时候才能确定下来的。

其次，需要开启 UglifyJsPlugin 这个插件对代码进行压缩。

（编辑：ASP站长网）