小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。

本文已参与「掘力星计划」，赢取创作大礼包，挑战创作激励金

大家好，我是山月。

这是我在掘金发表的前端工程化知识卡片集合 2/36

带指纹资源: 永久缓存

Cache-Control: public,max-age=31536000,immutable

天下武功，无坚不摧，唯快不破。资源请求最快的方式就是不向服务器发起请求，通过以上响应头可以对资源设置永久缓存。

1. 静态资源带有 hash 值，即指纹
2. 对资源设置一年过期时间，即 31536000，一般认为是永久缓存
3. 在永久缓存期间浏览器不需要向服务器发送请求

那为什么带有 hash 值的资源可以永久缓存呢？

因为该文件的内容发生变化时，会生成一个带有新的 hash 值的 URL。 前端将会发起一个新的 URL 的请求。

非带指纹资源: 每次进行新鲜度校验

Cache-Control: no-cache
Etag: helloshanyue

1. 由于不带有指纹，每次都需要校验资源的新鲜度。(从缓存中取到资源，可能是过期资源)
2. 如果校验为最新资源，则从浏览器的缓存中加载资源

index.html 为不带有指纹资源，如果把它置于缓存中，则如何保证服务器刷新数据时，被浏览器可以获取到新鲜的资源？

因此，使用 Cache-Control: no-cache 时，客户端每次对服务器进行新鲜度校验。

PS：no-cache 与 no-store 的区别是什么？

即使每次校验新鲜度，也不需要每次都从服务器下载资源: 如果浏览器/CDN上缓存经校验没有过期。这被称为协商缓存，此时 http 状态码返回 304，指 Not Modified，即没有变更。

幸运的是，关于协商缓存，你无需管理，也无需配置， nginx 或者一些 OSS 都会自动配置协商缓存。

而对于协商缓存，也有它们自己的算法，协商缓存的背后基于响应头 Last-Modified/ETag。浏览器每次请求资源时，会携带上次服务器响应的 ETag/Last-Modified 作为标志，与服务端此时的 ETag/Last-Modified 作比较，来判断内容更改。

而在操作系统底层，Last-Modified 往往通过文件系统(file system)中的 mtime 属性生成。而 ETag 提供比 Last-Modified 更精细的检验粒度，由文件内容的 hash 或者 mtime/size 生成。当然，这是后话。

总结

关于 http 缓存配置的最佳实践为以下两条：

1. 文件路径中带有 hash 值：一年的强缓存。因为该文件的内容发生变化时，会生成一个带有新的 hash 值的 URL。前端将会发起一个新的 URL 的请求。配置响应头 Cache-Control: public,max-age=31536000,immutable
2. 文件路径中不带有 hash 值：协商缓存。大部分为 public 下文件。配置响应头 Cache-Control: no-cache 与 etag/last-modified

但是当处理永久缓存时，切记不可打包为一个大的 bundle.js，此时一行业务代码的改变，将导致整个项目的永久缓存失效，此时需要按代码更新频率分为多个 chunk 进行打包，可细粒度控制缓存。

1. webpack-runtime: 应用中的 webpack 的版本比较稳定，分离出来，保证长久的永久缓存
2. react/react-dom: react 的版本更新频次也较低
3. vendor: 常用的第三方模块打包在一起，如 lodash，classnames 基本上每个页面都会引用到，但是它们的更新频率会更高一些。另外对低频次使用的第三方模块不要打进来
4. pageA: A 路由页面，当 A 页面的组件发生变更后，它的缓存将会失效
5. pageB: B 路由页面
6. echarts: 不常用且过大的第三方模块单独打包
7. mathjax: 不常用且过大的第三方模块单独打包
8. jspdf: 不常用且过大的第三方模块单独打包