字体图标加载失败主因是Nginx跨域配置不全：需在location块中同时配置具体来源、OPTIONS预检响应及正确MIME类型，且CDN与缓存常干扰生效。
字体图标加载失败，八成是 Nginx 跨域配置没生效，而不是前端路径写错了。核心问题在于：浏览器对 @font-face 加载的字体（.woff、.ttf、eot 等）执行更严格的 CORS 校验，仅配 Access-Control-Allow-Origin 往往不够，还缺预检支持和 MIME 类型兜底。
字体跨域比普通静态资源更敏感
普通图片或 JS 文件跨域失败时，控制台报错较明确；而字体文件被拦截后，往往静默失败——页面只显示方块或默认字体，控制台可能无错误，或仅提示 “Failed to load resource” 且状态码为 0。这是因为：
- 浏览器在加载字体前会先发一个
OPTIONS预检请求，若 Nginx 未正确响应，后续 GET 请求直接被拦掉 - 部分老旧浏览器（如 IE11）对
Access-Control-Allow-Origin: *和Credentials共存不兼容，若前端带 cookie，必须指定具体域名而非通配符 - 字体文件若被识别为
text/plain或application/octet-stream，即使头信息正确，也会因 MIME 类型不匹配导致解析失败
关键配置必须覆盖三类要素
仅在 server 块加一句 add_header 不足以稳定生效。需在匹配字体后缀的 location 块中完整设置：
-
允许来源：用具体域名替代
*（如https://your-app.com），尤其当前端携带认证信息时 -
预检支持：显式处理
OPTIONS方法，返回 204 并带上全部 CORS 头 -
MIME 映射：确保
mime.types已加载，且包含font/woff2 woff2;、font/ttf ttf;等条目
示例配置片段：
location ~* \.(eot|ttf|woff|woff2|svg|otf)$ {
add_header 'Access-Control-Allow-Origin' 'https://your-app.com';
add_header 'Access-Control-Allow-Methods' 'GET, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
<pre class='brush:php;toolbar:false;'>if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' 'https://your-app.com';
add_header 'Access-Control-Allow-Methods' 'GET, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204;
}}
CDN 和缓存常是“隐形杀手”
即使 Nginx 本机配置正确，字体仍加载失败，大概率是 CDN 层或浏览器缓存了旧响应：
- CDN 默认不透传自定义响应头，需在 CDN 控制台手动开启
Access-Control-Allow-Origin等头的回源与透传 - CDN 缓存了未带 CORS 头的字体响应，需强制刷新 CDN 缓存（非仅刷新页面）
- 浏览器已缓存失败响应（如 404 + 无 CORS 头），需清空浏览器缓存或使用隐身窗口验证
- 某些 CDN（如 Cloudflare）默认启用“浏览器完整性检查”，可能干扰字体请求，临时关闭可辅助排查
验证是否真正生效
别只看控制台有没有红字，要抓包确认三点：
- 用
curl -I https://your-domain.com/fonts/iconfont.woff查看响应头是否含Access-Control-Allow-Origin - 在 Chrome DevTools 的 Network 面板中，筛选
Font类型，点开字体请求，确认 Headers → Response 中存在全部 CORS 头，且 Status 是 200（非 304 或 206） - 观察是否有
OPTIONS请求发出并返回 204；若没有，说明浏览器认为无需预检（同源或简单请求），此时应检查协议、端口、域名是否真一致
