模块热替换功能会在应用程序运行过程中替换、添加或删除模块，而无需重新加载页面。这使得你可以在独立模块变更后，无需刷新整个页面，就可以更新这些模块，极大地加速了开发时间。
你可以设置 HMR，使此进程自动触发更新，或者你可以选择要求在用户交互后进行更新。
除了普通资源，编译器(compiler)需要发出 "update"，以允许更新之前的版本到新的版本。"update" 由两部分组成：
manifest 包括新的编译 hash 和所有的待更新 chunk 目录。
每个待更新 chunk 包括用于与所有被更新模块相对应 chunk 的代码（或一个 flag 用于表明模块要被移除）。
编译器确保模块 ID 和 chunk ID 在这些构建之间保持一致。通常将这些 ID 存储在内存中（例如，当使用 webpack-dev-server 时），但是也可能将它们存储在一个 JSON 文件中。
HMR 是可选功能，只会影响包含 HRM 代码的模块。举个例子，通过 style-loader 为 style 样式追加补丁。
为了运行追加补丁，style-loader 实现了 HMR 接口；当它通过 HRM 接收到更新，它会使用新的样式替换旧的样式。
类似的，当在一个模块中实现了 HMR 接口，你可以描述出当模块被更新后发生了什么。然而在多数情况下，不需要强制在每个模块中写入 HMR 代码。如果一个模块没有 HMR 处理函数，更新就会冒泡。这意味着一个简单的处理函数能够对整个模块树(complete module tree)进行处理。如果在这个模块树中，一个单独的模块被更新，那么整个模块树都会被重新加载（只会重新加载，不会迁移）。
对于模块系统的 runtime，附加的代码被发送到 parents 和 children 跟踪模块。
在管理方面，runtime 支持两个方法 check 和 apply。
check 发送 HTTP 请求来更新 manifest。如果请求失败，说明没有可用更新。如果请求成功，待更新
chunk 会和当前加载过的 chunk 进行比较。对每个加载过的 chunk，会下载相对应的待更新 chunk。当所有待更新 chunk
完成下载，就会准备切换到 ready 状态。
apply 方法将所有被更新模块标记为无效。对于每个无效模块，都需要在模块中有一个更新处理函数，或者在它的父级模块们中有更新处理函数。否则，无效标记冒泡，并将父级也标记为无效。每个冒泡继续直到到达应用程序入口起点，或者到达带有更新处理函数的模块（以最先到达为准）。如果它从入口起点开始冒泡，则此过程失败。
之后，所有无效模块都被（通过 dispose 处理函数）处理和解除加载。然后更新当前 hash，并且调用所有 "accept" 处理函数。runtime 切换回闲置状态，一切照常继续。
你可以在开发过程中将 HMR 作为 LiveReload 的替代。webpack-dev-server 支持热模式，在试图重新加载整个页面之前，热模式会尝试使用 HMR 来更新。查看如何实现在 React 项目中使用 HRM 为例。
一些 loader 已经生成可热更新的模块。例如，style-loader 能够置换出页面的样式表。对于这样的模块，你不需要做任何特殊处理。
webpack 的强大之处在于它的可定制化，取决于特定项目需求，这里有许多配置 HMR 的方式。