Manifest

在使用 webpack 构建的典型应用程序或站点中，主要有三种类型的代码：

1. 你（也许还有你的团队）编写的源代码。
2. 你的源代码所依赖的任何第三方库或“vendor”代码。
3. 负责所有模块交互的 webpack runtime 和 manifest。

本文将重点介绍这三部分中的最后一部分：runtime，尤其是 manifest。

Runtime

Runtime 以及 manifest 数据，是 webpack 在浏览器中运行时连接模块化应用程序所需的全部代码。它包含连接模块交互所需的加载和解析逻辑。这包括连接已经加载到浏览器中的模块，以及用于懒加载尚未加载的模块的逻辑。

Manifest

当你的应用程序以 index.html 文件的形式进入浏览器时，必须加载并链接你的应用程序所需的一些 bundle 和各种其他资源。你精心布局的 /src 目录现在已经被打包、压缩，并且可能已经被 webpack 通过 optimization 分成更小的 chunk 以进行懒加载。那么 webpack 如何管理所有必需模块之间的交互呢？这就是 manifest 数据的用武之地……

当编译器进入、解析并映射你的应用程序时，它会保留关于所有模块的详细记录。这个数据集合被称为“Manifest”，runtime 将使用它来在模块被打包并发送到浏览器后解析和加载模块。无论你选择了哪种 模块语法，那些 import 或 require 语句现在都变成了指向模块标识符的 __webpack_require__ 方法。利用 manifest 中的数据，runtime 将能够找到如何获取这些标识符背后的模块。

问题所在

现在你稍微了解了 webpack 在幕后是如何工作的。“但是，这对我有什么影响呢？”你可能会问。大多数时候，它没有影响。Runtime 会利用 manifest 完成它的工作，一切在你的应用程序进入浏览器后似乎都在神奇地运转。然而，如果你决定通过利用浏览器缓存来提升项目性能，那么这个流程将突然变成一件需要理解的重要事情。

通过在 bundle 文件名中使用内容哈希，你可以向浏览器指示文件内容何时发生了变化，从而使缓存失效。一旦你开始这样做，你很快就会注意到一些奇怪的行为。某些哈希值会发生变化，即使其内容显然没有变化。这是由 runtime 和 manifest 的注入引起的，它们会随每次构建而改变。

请参阅我们的 输出管理 指南中的 manifest 部分 来了解如何提取 manifest，并阅读下面的指南以了解更多关于长期缓存的复杂性。