在使用 webpack 構建的典型應用程序或站點中，有三種主要的代碼類型：

1. 你或你的團隊編寫的源碼。
2. 你的源碼會依賴的任何第三方的 library 或 "vendor" 代碼。
3. webpack 的 runtime 和 manifest，管理所有模塊的交互。

本文將重點介紹這三個部分中的最后部分：runtime 和 manifest，特別是 manifest。

runtime

runtime，以及伴隨的 manifest 數據，主要是指：在瀏覽器運行過程中，webpack 用來連接模塊化應用程序所需的所有代碼。它包含：在模塊交互時，連接模塊所需的加載和解析邏輯。包括：已經加載到瀏覽器中的連接模塊邏輯，以及尚未加載模塊的延遲加載邏輯。

manifest

一旦你的應用在瀏覽器中以 ?index.html? 文件的形式被打開，一些 bundle 和應用需要的各種資源都需要用某種方式被加載與鏈接起來。在經過打包、壓縮、為延遲加載而拆分為細小的 chunk 這些 webpack 優(yōu)化 之后，你精心安排的 ?/src? 目錄的文件結構都已經不再存在。所以 webpack 如何管理所有所需模塊之間的交互呢？這就是 manifest 數據用途的由來……

當 compiler 開始執(zhí)行、解析和映射應用程序時，它會保留所有模塊的詳細要點。這個數據集合稱為 "manifest"，當完成打包并發(fā)送到瀏覽器時，runtime 會通過 manifest 來解析和加載模塊。無論你選擇哪種 模塊語法 ，那些 ?import? 或 ?require? 語句現(xiàn)在都已經轉換為 ?__webpack_require__? 方法，此方法指向模塊標識符(module identifier)。通過使用 manifest 中的數據，runtime 將能夠檢索這些標識符，找出每個標識符背后對應的模塊。

問題

所以，現(xiàn)在你應該對 webpack 在幕后工作有一點了解。“但是，這對我有什么影響呢？”，你可能會問。答案是大多數情況下沒有。runtime 做完成這些工作：一旦你的應用程序加載到瀏覽器中，使用 manifest，然后所有內容將展現(xiàn)出魔幻般運行結果。然而，如果你決定通過使用瀏覽器緩存來改善項目的性能，理解這一過程將突然變得極為重要。

通過使用內容散列(content hash)作為 bundle 文件的名稱，這樣在文件內容修改時，會計算出新的 hash，瀏覽器會使用新的名稱加載文件，從而使緩存無效。一旦你開始這樣做，你會立即注意到一些有趣的行為。即使某些內容明顯沒有修改，某些 hash 還是會改變。這是因為，注入的 runtime 和 manifest 在每次構建后都會發(fā)生變化。

查看 管理輸出 指南的 manifest 部分，了解如何提取 manifest，并閱讀下面的指南，以了解更多長效緩存錯綜復雜之處。

Further Reading

• 分離 manifest
• 使用 webpack 提供可預測的長效緩存
• 緩存