【发布时间】：2020-01-14 13:33:30
【问题描述】：
启用 Chrome 的缓存后，我在 Chrome 中呈现 FontAwesome (v4) webfont 图标时遇到问题。间歇性地，在多台用户机器上，一个页面将加载我们的 FontAwesome 图标，如下所示。此问题仅偶尔发生，无法可靠地复制或缩小到单个页面。唯一常见的重现步骤是使用 Chrome 并且不在开发工具或其他地方启用了“禁用缓存”。
检查开发工具计算的图标元素样式显示 Chrome 正确地将指定的字体系列检测为“FontAwesome”，但图标的 <i> 标签以 Times New Roman 而非 FontAwesome 网络字体呈现. “FontAwesome”@font-face 声明和将font-family: FontAwesome 分配给.fa 类的上述规则存在于同一样式表site.css 中，这导致了问题。
检查下面的来源，我们看到site.css 在站点的<head> 标记中正确指定。它没有通过 JavaScript 添加到<head>；它出现在浏览器加载的初始页面中。 href 指向正确的样式表，在新选项卡中打开时加载没有问题。这并不奇怪，因为site.css 中指定的所有样式都正确地应用于页面（当然除了 webfont）。甚至 .fa 的 font-family 规则也被 Chrome 正确读取，如上面屏幕截图中的计算样式所示。
我怀疑 Chrome 正在以一种奇怪的方式从缓存中加载样式表，这种方式允许加载所有样式，但会干扰 FontAwesome 网络字体的创建。可能的证据如下：
以上是开发工具会话中网络选项卡的一部分。没有任何内容被过滤掉，但site.css 在请求列表中没有条目，即使存在其他缓存样式表并且来自site.css 的样式正在应用于页面。在同一 <head> 块中，紧接在 site.css 之后指定了 theme.css、jQuery、AdminLTE 和其他样式表的条目。图中未显示，但在“FontAwesome”的site.css 的@font-face 声明中指定的 fontawesome.woff2 webfont 文件也已成功加载。
刷新页面或导航到另一个页面有时可以解决问题。在禁用缓存的情况下刷新总是解决了这个问题。我们（相当大的）网络应用程序的每个页面都使用相同的<link> 标签加载此样式表，虽然这个问题很少出现，但在许多页面中都发生过。 site.css 样式表显然是由 Chrome 加载的，因为它会看到 font-family: FontAwesome 规则以及我们网站的其他样式。但在从缓存加载样式表的过程中似乎发生了一些事情，导致 Chrome 回退到 Times New Roman，尽管 webfont 既通过 @font-face 声明并指定为受影响元素的 font-family。
我们没有使用服务工作者或任何服务器端缓存。我们通过 GET 参数进行一些缓存清除，如上面的屏幕截图（?[productName]Version=2.0.13292.0）所示，该值被烘焙到由 ASP.NET 加载的初始文档中，并且仅在我们的后端服务器版本更改时才更改 - 所以不应该是这里问题的原因。
有没有人在使用 Chrome 网络字体时遇到过类似的情况？
【问题讨论】：
-
您是在使用 FA 的 CDN，链接到字体/js，还是自托管字体文件 (woff2)？此外，是否有任何构建脚本正在处理字体文件？您是否为静态文件设置了任何标头缓存策略？
-
@BryceHowitson 我们自托管字体文件，我们不会在构建脚本中修改它们，并且在提供这些静态文件时我们不会应用任何与缓存相关的标头。只是 IIS 的默认静态文件服务。
标签： css google-chrome caching font-awesome webfonts