一个很奇怪的浏览器缓存问题——字体文件为什么不走协商缓存？

Question

如题，最近发现了一个奇怪的问题，想问一下大佬们，浏览器会对字体文件缓存做一些特殊的处理吗？
具体表现如下：

注：请求为https://xxx/xxx/xxx/xxx.woff

在完全清除浏览器缓存后，第一次请求如图：

第一次请求状态是符合预期的200 OK，同时可以看到响应头中是存在cache-control:no-cache以及Etag和Last-Modified的
刷新页面，第二次请求如图：

可以看到请求状态是304 Not Modified，这也是符合预期的，因为上一次的响应中有cache-control:no-cache、Etag和Last-Modified，此时应该是协商缓存，请求头中也确实有If-Modified-Since以及If-None-Match，资源并没有更新因而返回304
但是再次刷新页面，就会发现第三次请求如图：

此时，请求状态竟然是200 OK (来自内存缓存)，也就是说并没有走协商缓存，而是类似强缓存一样直接命中了。
问题是，响应中依然有cache-control:no-cache、Etag和Last-Modified字段，难道不应该每次都走协商缓存发请求进行验证吗，尝试对比了一下，发现js、css还有图片文件都是每次走协商缓存进行验证(304)，只有字体文件有这么特殊的表现，难道浏览器会对字体文件缓存做一些特殊的处理吗？
求大佬们解惑~

Answer 1

我想这是浏览器特意为之，因为一般情况下字体文件并不会经常改变