都晓得 http 的申请头和响应头都能够设置 cache-control 属性，它的作用是用来设置动态资源缓存的。难道他们就没有什么不一样的中央么？反正一开始我是不明确，在网上也硬是没找到答案，于是这篇文章就进去了。。。
以下是本次验证的代码：
客户端为了验证申请头 cache-control 的作用，所以采纳了 ajax 的形式来申请 js。服务端次要是用来设置动态资源的缓存工夫的。咱们所说的缓存都是建设在 get 申请形式之上，其余形式设置的缓存临时没听说过哈
上面就是见证奇观的时刻：
场景一：当客户端、服务端都不设置 cache-control 的时候看看是什么状况
发现默认状况下是不会走缓存的
场景二：当服务端设置 cache-control，客户端没有设置的时候看看是什么状况
发现缓存是由服务端开启的
场景三：当客户端设置 cache-control，服务器端没有设置的时候看看是什么状况
发现当只有客户端开启 cache-control 时是不会失效的，缓存必须是由服务端开启
场景四：当客户端和服务端都设置了 cache-control 的时候看看是什么状况
发现 30 秒后缓存就生效了，而不是客户端设置的 60 秒，故缓存的生效工夫是由服务端设置决定的
场景五：当客户端设置不须要缓存，而服务端设置了缓存的时候看看什么状况
发现资源不再走强缓存了，而是间接向服务器发送了申请，故申请头中设置的 cache-control 是能够不走缓存的，cache-control: max-age= 0 这和按 F5 键是一样的成果
论断：
1、只有服务端能力开启缓存，默认是不会走缓存的
2、走了强缓存就不会再向服务端发送申请了
3、客户端的申请头中只有设置了 cache-control 为：’no-store’ | ‘no-cache’ | ‘max-age=0’ 才会失效（也就是客户端不想走强缓存的时候失效），除非后端对这个字段做非凡解决
如果有对强缓存和协商缓存不太分明的同学能够理解一下之前写过的一遍文章一文读懂 http 缓存（超具体）