深度解读chrome浏览器对资源文件的缓存规则
我们都知道浏览器是有缓存功能的
它会自动缓存一些资源文件
前两天一个小伙伴问我这样一个问题
他们啊有一个公用的登录系统
然后呢还有一个子系统
登录成功呢
会自动跳转到这个子系统
（但是呢这两个系统是存在跨域的哈）
那现在什么问题呢
就是这个子系统啊
因为vue做的
它有一个script脚本特别大
这个app.js
比如说然后呢
他现在想怎么解决呢
他说：我能不能在这个登录页
就把这个app.js啊
给加载一下
这是登录页
然后当他登录成功
来到这个子系统的时候呢
他因为走缓存就很快了嘛
但是呢他试了一下
为什么这样就不行
好记得吧
（这里是存在跨域的）
好我们来看一下chrome的官方文档
在其实在85这个版本之前啊
他这样做是没有问题的
因为这个缓存的key值啊
就是很简单的是这个资源的路径
然后呢从86这个版本之后
也就说2020年10月份之后
他这个缓存的key值变成了这个样子
由三部分组成
第一部分呢
就是最外层的这个地址栏
输入的这个有效的域名
（什么叫有效的域名后面我们再说啊）
加上这个协议
然后第二部分呢
是他当前所在的
frame的有效域名和协议
第三部分才是这个资源的地址
我们来验证一下哈
他下面有一个工具
我们在这我们用chrome我们来测哈
这一个网络日志的功能哈
我们在开启之前先把这个缓存清一下
好然后呢我们开启日志
选择一个位置保存到桌面
然后这我们准备了一个demo哈
访问的是b.com
然后里边嵌套了一个a.com的iframe
注意啊我刷新
大家看现这两个资源文件
一个是js
一个是图片
都是走的网络
当我们再次刷新的时候
大家看已经变成缓存了
然后呢这个文档里
还给了一个解析日志的工具
然后呢打开这个文件夹了进来
注意看这个Events
这里边呢
我们找到刚才那个资源的地址
这个
然后这里边呢是正在写日志
注意看这有个key
这个key啊
跟它（格式）官方文档虽然不太一样哈
但是呢我们可以窥见一些东西
大家看前面这个
就是我外边访问的这个
可用的域名加协议
http + b.com
然后第二段呢
就是里边这个iframe的
然后最后呢是这个资源的地址
他把整个这个当作一个key值
所以呢我们再回来看这个文档的话
其实就很容易了
他其实就说了这么几件事
第一个呢
因为跨域
你访问a.example和b.example的话
虽然是同一个资源
但它命中不到刚才的缓存
然后从第二个问题开始
都是带frame的了
你看第二个
他访问了一个a.example
里边存在一个frame
但这frame也是a.example
所以呢
它的key值跟刚才的key值是一样的
所以它这个能命中
但是如果a.example
嵌套了一个c.example
这个key值就不一样了
所以它命中不到缓存
再往下的话呢
这是子域名的问题
因为它使用的是eTLD+
所以这个子域名会忽略掉
（这个一会我们来讲哈）
然后再往下
中间嵌套了很多层frame的情况下
他会忽略到中间那些层
只会看最外层浏览器的那一个
和他资源文件所在的那个frame
那所以我们再回到刚才的问题
我们能不能在这个登录页里边
用frame来解决问题呢
就是我们在登录页里
用隐藏的iframe来嵌套这个子系统
这样也是不行的
因为它缓存的key值不同
最终还是命中不到
那最后呢
我们来看到底什么是这个eTLD哈
（就是这个可用域名）
假如让你写一款浏览器
你肯定希望在安全的前提下
最大程度的去使用缓存
比如这abcd.com
不管它前面是www.abcd也好
或者doc.abcd也好
只要是abcd.com
都能使用同样的缓存
那我们能不能在程序里写死呢
就看最后一个点的前后这两部分呢
比如说abc.net
这种域名看起来可以哈
这种其实.com啊.net呀
它比较单一
但是呢还有一种域名
它是两级的
比如说像这种.gov.cn
或者.com.cn
它是两级的
这时候呢
就不能把它当成一个key值了
这样就乱了
像这种.com啊
.net啊
.cn啊都是顶级域名
叫：top level domain（TLD）
但是呢
不能拿这个顶级域名直接去写程序
所以呢又出现了一种叫eTLD
叫可用的顶级域名
这个单词是这个effective
那这些列表在哪维护呢
在这里这有一个网址
然后呢我们点这个list
这里边会定期的更新这些eTLD
好回过头我们再来看这个文档
它这个key值啊
用的就是协议
就 http/https 加上 eTLD+
也就是说eTLD是可用域名嘛
比如说.com.cn
其实是一个可用域名
前面加一是什么呢
比如说test.com.cn
那像.com是一个eTLD
那abcd.com就是eTLD+1了
最后更新于