web.dev检测字体CORS拦截 配置.htaccess后仍报错如何解决

按以下优先级逐一排查，绝大多数同类问题都可定位解决：

• 先确认Web服务器类型：.htaccess是Apache服务器专用的分布式配置文件，若使用Nginx、Caddy等其他服务，写在.htaccess里的规则完全不会生效。如果是Nginx环境，直接删除.htaccess内的相关配置，在站点对应的Nginx配置文件中添加如下规则，重载Nginx配置即可生效：

location ~* \.(ttf|ttc|otf|eot|woff|woff2|font.css)$ {
    add_header Access-Control-Allow-Origin "*";
}

• 确认Apache的mod_headers模块已启用：你添加的配置包裹在<IfModule mod_headers.c>标签内，若模块未启用，整段配置会被直接跳过不执行。验证方法：在.htaccess中添加一行测试规则Header set X-Test-Module "enabled"，之后直接请求站点上的任意字体文件，查看响应头中是否存在X-Test-Module字段。如果不存在，说明mod_headers未开启：自建Apache服务执行a2enmod headers后重启Apache即可；虚拟主机用户直接联系主机商开启该模块。
• 确认.htaccess文件具备生效权限：Apache默认会关闭目录级配置覆盖权限，若站点对应目录的主配置中AllowOverride参数值为None，.htaccess文件不会被服务器读取。验证方法：在.htaccess中随便写入一行无效指令比如InvalidTestRule，访问站点任意页面如果没有返回500错误，即可确认.htaccess未生效。需要修改Apache主配置中对应站点目录的AllowOverride All，重启服务后即可。
• 确认字体资源的存储位置：如果字体文件托管在CDN、独立静态资源域名、第三方对象存储上，写在主站根目录的.htaccess规则无法作用于这些资源。需要去CDN后台、对象存储后台单独配置跨域响应头，同时确保CDN回源时不会覆盖源站返回的CORS头。
• 排查缓存干扰：
  1. 先清空本地浏览器缓存，开隐私窗口访问站点，在开发者工具网络面板中找到字体请求，确认响应头中已经携带Access-Control-Allow-Origin: *字段，本地访问都看不到该头的话，不用提交web.dev检测，先解决配置生效问题。
  2. 清空服务端全链路缓存：包括站点静态资源缓存、CDN边缘节点缓存、对象存储缓存，web.dev的检测节点会缓存首次抓取的响应结果，清完缓存后等待10-15分钟再重新提交检测。
• 排查规则冲突与覆盖问题：检查.htaccess中是否存在后续规则unset掉了Access-Control-Allow-Origin头，或者Apache主配置中存在优先级更高的CORS规则覆盖了你写的配置。另外确认站点的字体请求路径能被FilesMatch的正则命中，如果是动态输出的字体资源（路径无对应后缀），需要额外匹配对应路径添加CORS头。

内容的提问来源于stack exchange，提问作者Zhivko Zhelev