webpack热更新，也称热替换，英文缩写HMR(Hot Module Replacement)。ok，介绍完定义，那么HMR的作用是什么呢？答案是让web项目可以在开发环境下，每次更改文件后无需重刷浏览器，即可看见更改的效果。嗯，了解完这些后，让我来抛出以下问题：

怎么打造一个高效的开发环境？
我在开发环境中咋没见过webpack构建的资源呢？
浏览器怎么知道要更新哪些内容？
为什么有时候更改代码是热更新、有时候浏览器刷新呢？

相信实际开发中，我们很少去想过以上的问题，“管他呢能用就行”“项目进度赶得飞起”是很多人的常态，就算想去了解也被动不动整篇都讲源码的文章吓跑。本篇文章希望通过大白话，让读者能够了解热更新是什么，帮开发做了什么。当然了，大白话讲的意思就是不要出现整段整段的代码，尽量争取简单易懂。

先讲下webpack与开发环境

实际开发中我们都会用现成的脚手架去创建项目，用成熟脚手架创建的项目自然也就带上了一系列开发环境配置，比如热更新。那如果我们不用脚手架呢？从零开始会是什么样，看以下几个阶段：

手工劳作阶段：代码更新 >> 手动webpack构建 >> 生成打包资源 >> 手动刷新浏览器看效果。这一阶段全靠手动操作。
watch阶段，使用webpack --watch模式启动项目：代码更新 >> 自动webpack构建 >> 生成打包资源 >> 手动刷新浏览器。这一阶段每次更新代码后，不用手动构建一次了，webpack自动构建代码，提效了一部分。
devServer阶段：在第2阶段的基础上，增加了一个静态资源服务器
热更新阶段：代码更新 >> 触发webpack自动构建 >> 浏览器自动替换变更模块

通过这几个阶段演进，可以看到开发的效率越来越高，从这里我们看到了一个高效的开发环境，但中间依然有几个疑点，比如阶段3之前，我们可以看到构建后有资源文件的产出（默认输出到根目录下的dist目录），但热更新阶段却并没有看到每次构建产生的包，那构建资源到哪去了呢？其次，浏览器怎么知道要更新哪一块内容呢？在回答这些问题之前，让我们先看看一些名词定义。

先了解一些名词

关于webpack-dev-server(以下称WDS)：一个基于node.js和webpack的简易服务器，限开发时使用。WDS包含三个核心功能，分别是提供一个简易的web服务器、webpack-dev-middleware以及webpack-dev-server/client。
关于webpack-dev-middleware：一个中间件，用于与webpack的compiler对象绑定，在dev-server启动时会调用，限开发使用。有以下三个特性：
- 通过watch mode，监听资源变更，然后自动打包。
- 打包后的文件存入内存中，而不是磁盘。
- 支持HMR
关于webpack-dev-server/client：与服务端进行一个websocket连接，并对服务端的消息作出响应及消息传递。
关于HMR.runtime：HotModuleReplacementPlugin插件提供，用于在浏览器端请求更新后的资源以及进行热替换操作。
关于webpack/hot/dev-server：根据webpack-dev-server/client传递的消息，决定是进行live reload浏览器刷新还是热更新。

热更新流程

相信通过对一些名词的解释，有的人大体已经猜到热更新的流程，接下来大体走一遍步骤。

在webpack watch模式下更新代码，webpack会自动进行构建。顺带提一下，以webpack-dev-server运行默认watch:true。
WDS与webpack之间进行交互，实际上是由WDS的中间件webpack-dev-middleware与webpack进行接口交互，webpack-dev-middleware对webpack暴露的api进行监控并告诉webpack将资源打包到内存中，保存为一个Javascript对象。
如果在webpack中配置了devServer.watchContentBase: true，WDS会监听配置中的静态文件的变化，并进行live reload浏览器刷新，注意是直接刷新。静态文件什么意思呢？就比如.html文件等entry入口找不到的文件。
通过WDS里的sockjs在浏览器端和服务器之间建立websocket长连接。这一步的目的是将webpack编译打包的各个阶段状态告知浏览器，让浏览器端可以根据这些消息进行不同的操作，主要传递的还是新模块的hash值。这里涉及浏览器端中webpack-dev-server/client，问题来了，这东西什么时候在浏览器端代码中的呢？先存个疑。
这一步是判断步骤，webpack/hot/dev-server会根据上一步中webpack-dev-server/client传递的状态及dev-server的配置，决定是刷新浏览器还是进行热更新，如果是热更新则进入下一步，如果是刷新浏览器则流程到此结束。
HMR.runtime登场，它接收到webpack-dev-server/client传递的新模块hash值，然后通过JsonpMainTemplate.runtime向server端发送Ajax请求，请求返回一个json，包含了所有要更新的模块hash值，然后该模块再通过jsonp请求，获取到最新的模块代码。
更新模块，HMR会对新旧模块进行对比，决定是否更新模块，决定更新后，检查模块之间的依赖关系，更新模块的同时更新模块间的依赖引用。
如果上一步HMR更新失败，则回退到live reload的操作。

补充

以下内容是对本篇文章上述部分的补充

问题：webpack/Node.js如何监听文件变化？

查一下Node.js的文档，找到两个监听文件变化的API：fs.watch | fs.watchFile。
在webpack通过配置watch可以开启监听文件变化，原理如下：
在webpack中，监听一个文件发生变化的原理是定时获取该文件的最后编辑时间，如果发现该时间与上一次保存的时间不一致则认为该文件发生了变化。其中，我们可以在配置项watchOptions.poll中设置轮询的间隔时间。
在发现一个文件发生变动时，并不会马上通知监听者，而是先缓存起来，收集一段时间后，再通知。这段时间的配置可以在watchOptions.aggregateTimeout配置，默认值300ms

问题：HMR.runtime及webpack-dev-server/client何时注入到浏览器代码（即bundle）中?

HMR.runtime：是由HotModuleReplacementPlugin插入，现在默认在webpack/lib/HotModuleReplacement.runtime中
webpack-dev-server/client：WDS修改了webpack配置中的entry属性，在里面添加了webpack-dev-server/client的代码，这样在最后生成的bundle.js文件中就有了这一部分的代码了。

大白话讲webpack热更新