window.location.reload(true)弃用日记

笔者最近在学习HTTP缓存相关的知识，顺便验证项目的方案，验着验着发现出问题了，强制刷新浏览器缓存的代码不管用。

于是，查阅资料并顺手做个记录。

先上结论

强制刷新可以使用fetch，客户端发起请求时在请求头加Cache-Control参数。 参考文档

// no-cache:询问服务器资源是否有效，是否可用客户端缓存，可用返回304
// reload:直接向服务器拿最新资源
fetch("/", { cache: "no-cache" }); 
fetch("/", { cache: "reload" });

为什么弃用

项目代码使用的目的是强制刷新，从服务器获取最新脚本资源。

网络上有很多方案，不少建议用window.location.reload(true)，入参true可以起到强制刷新的效果。

但查阅MDN文档发现，reload参数并未入规范，浏览器不一定生效。

实际上也确实如此，直接F12控制台输入window.location.reload(true)，再看网络请求结果，发现走的是缓存。

资源替换验证

虽然查阅文档找到了方案，可还是有很多疑惑。比如浏览器资源缓存在哪里？缓存的资源如何更新？无法操作服务器的卑微本人，如何观察本地浏览器已经使用最新资源了呢？

一番查找之下，发现可以查看本地的浏览器缓存，通过比对更新时间、文件大小、名称来判断是否更新。

浏览器缓存文件-本地查看

以js脚本请求为例：app.66395802.js

1. 浏览器输入url进行查看 chrome://version/
2. 复制个人资料路径，进入文件夹查看，观察文件大小和修改日期

3. 再执行一次 fetch("/static/js/app.66395802.js", { cache: "reload" })

查看浏览器请求结果、文件夹刷新结果：可以观察到缓存资源直接被替换了，f_000646被替换成f_000647

4. 试试协商缓存 fetch("/static/js/app.66395802.js", { cache: "no-cache" })

新添资源f_00064b；旧资源f_000647还在，没有被替换

嗯，合理。

其他方案

顺路试试其他方案，都是一样走缓存，无强制刷新。

window.location.href = window.location.href
window.history.go(0)