本人翻译水平有限，译文中难免存在错误，欢迎指出并及时纠正。
Hot Module Replacement (热模块替换)
Hot Module Replacement (HMR) exchanges,adds,or removes while an application is running without a page reload. This allows you to speed up development time by updating individual modules when they are changed without refreshing the page.
热模块替换 (HMR) 在应用运行时交换，添加，或移除 而不用重载页面。不用刷新页面，当单个模块更改时只更新该模块，这可以提高你的开发效率。
How Does It Work? (它是如何工作的？)
From The App View (从 APP 视角)
The app code asks the HMR runtime to check for updates
The HMR runtime downloads the updates (asynchronously) and tells the app code that an update is available.
The app code then asks the HMR runtime to apply the updates.
The HMR runtime applies the update (synchronously) (HMR runtime 应用更新 (同步地)).
app 代码请求 HMR 运行时检查更新。
HMR 运行时下载更新 (异步地) 并告诉 app 代码更新可以使用。
app 代码然后请求 HMR 运行时应用更新。
HMR 运行时应用更新 (同步地)。
You can set up HMR so that this process happens automatically,or you can choose to require user interaction for updates to occur.
你可以设置 HMR 来使这个过程自动执行，或者你可以选择需要用户交互来触发更新。
From The Compiler (webpack) View (从编译器 (webpack) 视角)
In addition to the normal assets,the compiler needs to emit an "update" to allow updating from previous version to the new version. The "update" consists of two parts:
除了普通的资源，编译器需要发送 "update" 来更新版本。"update" 由 2 部分组成：
The update manifest (JSON)
One or more update chunks (JavaScript)
更新清单 (JSON)
一个或多个更新块 (JavaScript)
The manifest contains the new compilation hash and a list of all update chunks.
这个清单包含新的编译哈希值和所有更新块列表。
Each update chunk contains code for all updated modules in the respective chunk (or a flag indicating that the module was removed)
每一个更新块包含各自块中所有已更新的模块的代码 (或一个指示模块被删除的标识)
The compiler makes sure that module IDs and chunk IDs are consistent between these builds. It typically stores these IDs in memory (for example,when using webpack-dev-server),but it's also possible to store them in a JSON file.
编译器在这些构建中确保模块 IDs 和块 IDs 是一致的。它通常在内存中存储这些 IDs (比如，使用 时)，但也可以在 JSON 文件中存储它们。
From The Module View (从模块视角)
HMR is an opt-in feature that only affects modules containing HMR code. One example would be patching styling through the . In order for patching to work,style-loader implements the HMR interface; when it receives an update through HMR,it replaces the old styles with the new ones.
HMR 是一个可选功能，它只影响包含 HMR 代码的模块。一个例子是通过 修改样式。为了使修改生效，style-loader 实现了 HMR 接口；当它通过 HMR 接收到一个更新，它便用新的样式替换老的样式。
Similarly,when implementing the HMR interface in a module,you can describe what should happen when the module is updated. However,in most cases,it's not mandatory to write HMR code in every module. If a module has no HMR handlers,the update bubbles up. This means that a single handler can handle an update to a complete module tree. If a single module in this tree is updated,the complete module tree is reloaded (only reloaded,not transferred).
同样地，当在模块中实现 HMR 接口，你可以描述当模块更新时应该发生什么。但在大多数情况下，在每个模块中写 HMR 代码并非强制性的。如果一个模块没有 HMR 处理器，则更新向上冒泡。这意味着单个处理器可以处理更新到整个模块树。如果这个树中的单个模块被更新，则整个模块树重载 (只重载，不转移)。
From The HMR Runtime View (Technical) (从 HMR 运行时视角 (技术性的) )
For the module system runtime,additional code is emitted to track module parents and children.
对于模块系统运行时,发送额外的代码来跟踪模块的
parents和children。
On the management side,the runtime supports two methods: check and apply.
在管理方面，运行时支持两种方式：
check和apply。
A check makes an HTTP request to the update manifest. If this request fails,there is no update available. If it succeeds,the list of updated chunks is compared to the list of currently loaded chunks. For each loaded chunk,the corresponding update chunk is downloaded. All module updates are stored in the runtime. When all update chunks have been downloaded and are ready to be applied,the runtime switches into the ready state.
check发送一个 HTTP 请求到更新清单。如果请求失败，则没有可用的更新。如果成功，则比对已更新的块列表和当前已加载的块列表。对于每个已加载的块，下载对应的更新块。所有模块更新存储到 运行时。当所有更新块已下载并且准备应用，运行时切换到ready状态。
The apply method flags all updated modules as invalid. For each invalid module,there needs to be an update handler in the module or update handlers in its parent(s). Otherwise,the invalid flag bubbles up and marks its parent(s) as invalid too. Each bubble continues until the app's entry point or a module with an update handler is reached (whichever comes first). If it bubbles up from an entry point,the process fails.
apply方法标识所有已更新到模块为无效的。对于每个无效模块，需要的是在模块中的更新处理器或在它的父级中的更新处理器。否则，无效标识冒泡并标记它的父级也为无效的。每个冒泡持续到 app 的入口点或抵达有更新处理器的模块 (无论先抵达哪个)。如果从入口点冒泡，则该过程失败。
Afterwards,all invalid modules are disposed (via the dispose handler) and unloaded. The current hash is then updated and all "accept" handlers are called. The runtime switches back to the idle state and everything continues as normal.
之后，所有无效模块被处理 (通过处理处理器) 和卸载。然后当前的哈希值被更新以及所有 "accpet" 处理器呗被调用。运行时切换回
idle状态并且一切照常进行。
What can I do with it? (我可以用它做什么？)
You can use it in development as a LiveReload replacement. supports a hot mode in which it tries to update with HMR before trying to reload the whole page. See how to implement as an example.
你可以在开发中用它替代 LiveReload。 支持热模式，它在重载整个页面之前尝试用 HMR 更新模块。参考如何实现 的例子。
Some loaders already generate modules that are hot-updatable. For example,the style-loader can swap out a page's stylesheets. For modules like this,you don't need to do anything special.
webpack's power lies in its customizability,and there are many ways of configuring HMR depending on the needs of a particular project.
webpack 的能力来自它的自定义性，有许多配置 HMR 的方式，这取决于具体的项目需求。
