缓存重载

1. webpack 热重载的3种方式

开发阶段，如果每次文件变更后，都要手动去打包build是很不方便的，通常在开发阶段采用以下三种方式进行热重载（自动编译）

配置文件提供一个入口和一个出口，webpack根据这个来进行js的打包和编译工作。package.json文件增加watch脚本 --watch 动态监听文件的改变并实时打包，输出新的文件，这样文件多了之后速度会很慢，而且此打包方式不会热更新，即每次webpack编译之后，你还需要手动刷新浏览器。
缺点： 需手动刷新浏览器
优点： 自动编译

webpack-dev-server实际上相当于启用了一个express的Http服务器＋调用了webpack-dev-middleware【简单的web服务器和实时重载】。这个Http服务器和client使用了websocket通讯协议，原始文件做出改动后，webpack-dev-server会用webpack实时的编译，再用webpack-dev-middleware将webpack编译后的文件输出到内存中。【这边注意，最后的编译的文件并没有输出到目标文件夹，都保存到了内存】（适合纯前端项目，很难编写后端服务，进行整合）

优点： 自动编译 + 实时重新加载浏览器
webpack-dev-server

缺点： 需手动刷新浏览器 + 配置文件和插件多
优点： 自动编译

定义了webpack.config里的entry和output的关系脉络，webpack-dev-middleware能在此基础上形成一个文件映射系统，每当应用程序请求一个文件。它匹配到了就把内存中缓存的对应结果以文件格式返回，反之进入下一个中间件。

因为是内存型文件系统，所以重建速度非常快，很适合于开发阶段用作静态资源服务器；因为webpack可以把任何一种资源当作是模块来处理，因此能向客户端反馈各种格式的资源，所以可以替代HTTP服务器。

三者相比：观察模式在开发中不实用;web服务器实用性强；webpack中间件+express使用了2个插件，2个配置文件，配置复杂

事实上，大多数 webpack 用户用过的 webpack-dev-server 就是一个 express＋webpack-dev-middleware 的实现。

二者的区别仅在于 webpack-dev-server 是封装好的，除了 webpack.config 和命令行参数之外，很难去做定制型开发。而 webpack-dev-middleware 是中间件，可以编写自己的后端服务然后把它整合进来，相对而言比较灵活自由。

是一个结合webpack-dev-middleware使用的middleware，它可以实现浏览器的无刷新更新（hot reload），这也是webpack文档里常说的HMR（Hot Mole Replacement）。HMR和热加载的区别是：热加载是刷新整个页面。

运行方式：
1、命令行
package.json中指令加上 --hot

2、Nodejs API

热更新热重载
webpack-dev-server 自动打包/热重载

2. 重载是什么意思

重载是装运重物时的负载。

引证解释：

1、古时谓装载辎重等货物。

例句：杨伯峻注：重，重车，装载货物之车。

2、指装载辎重等货物的车辆。

例句：《宋史五行志一下》：雍熙二年冬，南康军大雨雪，江水冰，胜重载。

3、满载，超载。

例句：鲁迅《野草死后》：一辆独轮车从我的头边推过，大约是重载的。

4、指超载的车。

例句：叶圣陶《游临潼》：一辆大车往往挤着一二十人，骡子拉着重载本来跑得很慢。

5、方型压力开关有坚固的防腐蚀外壳，这保证了即使在重载的情况下，也有很长的使用寿命。

6、生命之舟如果缺少知识的重载，就会摇晃不停。

7、带有资源缓存的集合服务定位器创建全局缓存，通过这种方式不能为重载的资源名正确处理组件级映射。

8、金属盘片的抗冲击、耐热和化学物质耐受性能更佳，不会再重载环境中碎裂。

9、正如所预测的那样，重载的资源名和缓存服务定位器使得代码执行有不同的结果，它使某些组件取得错误的资源。

10、轧机轴承一般载荷条件是中重载荷和冲击载荷，因此，最适用的材料为渗碳轴承钢。

3. 如何重载浏览器 onload 事件后加载的资源文件

两个最佳的性能实践是 增添一个远期的失效时间和增加 延迟加载资源（特别是脚本）在onload事件之后。但是这些最佳实践的组合却导致了用户很难刷新资源的情况。更确切的说，点击重载（或甚至shift+重载）并不能在irefox, chrome, Safari, android,和 iPhone中刷新这些缓存的，延迟加载的资源。
我们期待重载能带来什么
浏览器有一个缓存（或10个），那里它保存响应的拷贝。如果用户感觉那些缓存的结果已经陈旧，她可以点击重载按钮忽略缓存并刷新一切，以此保证她看到的是网站内容的最新的拷贝。在HTTP规范中我找不到任何讨论重载按钮的资料，但据我所知所有浏览器都有这种特性。
如果你点击重载（或 control+R 或 command+R)，所有资源将以有条件的GET请求方式刷新(携有是否自上次以来修改和是否不匹配的校验)。如果服务器响应的版本没有变化，它会返回简短的不含响应主体的“304 Not Modified”状态。如果响应改变则响应“200 OK”并返回全部的响应主体。
如果你点击shift+Reload (或r control+Reload 或 control+shift+R 或 command+shift+R)，那么所有的资源就会用不带校验头的方式刷新。由于每个响应主体都会返回，这要低效一些，但是确保了所有缓存的失真的响应都被覆盖重写。
最起码，我们希望点击重载的时候得到网站资源的最新版本而不管其失效时间，shift+重载会更积极的做到这些。
欢迎重载2.0
在Web1.0时代，资源通过HTML标签的方式请求—IMG, SCRIPT, LINK等等。在Web2.0，资源经常被动态请求。两个普遍的例子是异步加载脚本（例如Google Analytics）和图片动态获取（例如旋转灯笼式图片或下方区域图片延迟加载）。有时这些资源在窗口onload之后被请求，以使主页能更快的渲染提供更好的用户体验，更好的指标等等。如果资源有一个很久以后的失效时间，浏览器则需要特别的智能去做正确的事情。
如果用户以正常方式浏览到该页(点击一个link，输入一个URL，利用一个书签等等)而且动态的资源在缓存中，浏览器将使用缓存拷贝（假设失效时间仍在未来）
如果用户重载了该页，浏览器将重新获取所有资源，包括页面中动态加载的资源。
如果用户重载了该页，我想onload处理程序中加载的资源也同样被重新获取。这些可能是页面基础架构的一部分，它们应当在用户想刷新页面内容的时候重新获取。
但是如果用户重载页面的时候，有资源在onload事件之后加载，浏览器在该做什么？有些web应用通过保存数小时乃至数天的session来保持活动状态。如果用户重载了，所有在web应用生命期内的动态的资源会忽略cache重新获取吗？

一个例子：
我们看一个例子：Postonload Reload
这个页面用五种不同的方式加载图片与脚本：
标签 – 基础的HTML途径：<img src=http://www.oschina.net/translate/和<script src=.
正文中动态 – 在页面正文中是一个脚本块，动态的创建一幅图片和一段脚本，设置SRC来获取资源。这些代码在onload之前执行。
加载时 – 在onload处理程序中动态的创建一段脚本和一幅图片。
加载后1 ms – 通过在onload处理程序中的1毫秒setTimeout回调，动态的创建一段脚本和一幅图片。
加载后5秒– 通过在onload处理程序中的5秒setTimeout回调，动态的创建一段脚本和一幅图片。
所有图片和脚本有一个未来一个月的失效期。如果用户点击重载，哪一个技术会重新获取？当然我们希望1和2可以引起重新获取。我希望3也重新获取。我想4应该会重新获取但是困惑于许多浏览器是否能做到，还有5可能不会重新获取。排一下你期待的结果然后看看下面的表格。
结果
在看重载的结果以前，我们看一下如果用户只是浏览到该页会发生什么。这是通过点击例子中“try again”链接实现的。在这种情况下，没有资源被重新获取。所有的资源都标着未来一个月失效期被存入缓存，所以我测试的浏览器都只是从缓存中读出它们。这很好正如我们预期。
但是我们看下面表中捕获的重载的结果，行为变得分化了。
Table 1. Resources that are refetched rel="nofollow">Google, YouTube, Yahoo, Microsoft Live, Tencent QQ, Amazon 和 Twitter。如果你用列出来的前四个浏览器，打开包嗅探器，重载这些网站的任何一个，你将看到一个奇怪的模式：可缓存的资源在onload之前加载，带有304响应状态，而onload之后的从缓存读出来并不会重新获取。唯一确保获得最新版本的办法是清空缓存，这使得重载按钮的期望价值破灭了。

这里是Amazon在Chrome浏览器下的请求瀑布流。红色竖线就是onload事件时刻。注意到多少资源在onload之间返回304状态。红线右侧onload之后一些图片不被缓存，所以被再请求返回200状态。而可以缓存的图片在onload之后都从缓存中读取，因此这些资源都得不到更新。

最后，无论何时都应该仔细研究不同浏览器的行为到底是为什么。经常一些行为优先于另一个，我们应该把这些特性和厂商对应起来。在重载页面的情况时，我们应该更一致地重新加载所有资源，即使是onload事件后的动态资源。