跨域字体拦截需前后端协同解决：css中@font-face必须加crossorigin: anonymous，服务端响应须含access-control-allow-origin等cors头，nginx配置需加always标志；若无法控制服务端，可采用base64内联、反向代理或本地托管。
跨域字体文件被浏览器拦截，核心原因是同源策略对 @font-face 加载的字体资源施加了 CORS 限制——即使 CSS 文件能正常加载，字体文件（如 .woff2、.ttf）若来自不同源且服务端未授权，浏览器就会静默拦截并报错。单靠前端改代码无法绕过，必须前后端协同解决。
确保 @font-face 显式声明 crossorigin
在 CSS 的 @font-face 规则中，必须加上 crossorigin: anonymous。这不是可选项，而是触发浏览器以 CORS 模式发起字体请求的必要标记：
示例：
@font-face {
font-family: 'IconFont';
src: url('https://cdn.example.com/fonts/icon.woff2') format('woff2');
font-display: swap;
crossorigin: anonymous; /* 关键：必须写 */
}
不加该属性，浏览器可能用普通非 CORS 方式请求，服务端即使返回了字体，也可能因缺少响应头而失败；加了但服务端没配头，依然报错——它只是“告诉浏览器要走 CORS 流程”，不是“打开免检通道”。
服务端必须返回正确的 CORS 响应头
字体文件所在服务器（CDN 或自有服务）需在响应中包含以下 HTTP 头：
-
Access-Control-Allow-Origin：设为具体域名（如
https://your-site.com），生产环境避免用*（尤其当字体请求需携带凭证时） -
Access-Control-Allow-Methods：至少包含
GET -
Access-Control-Allow-Headers（可选但推荐）：如
X-Requested-With, Content-Type -
always 标志不可少：Nginx 配置中需加
always，否则 304 或 404 响应不带 CORS 头，缓存或路径错误时仍会失败
Nginx 示例配置（精确匹配字体后缀）：
location ~* \.(woff2?|ttf|eot|otf|svg)$ {
add_header Access-Control-Allow-Origin "https://your-site.com" always;
add_header Access-Control-Allow-Methods "GET" always;
add_header Access-Control-Max-Age "31536000" always;
}
替代方案：当无法控制字体服务端时
如果你用的是第三方图标库（如 iconfont.cn），对方不支持白名单配置，或你无权修改其服务器设置，可考虑降级处理：
-
转 Base64 内联：适合图标字体（体积小），用工具如 transfonter.org 将字体转为 base64，直接嵌入
src: url(data:font/woff2;base64,...) - 反向代理：在自己后端加一层代理（如 Nginx rewrite 或 Node.js 中间件），把字体请求转发到目标地址，响应由自己服务发出，自然同源
- 本地托管：下载字体文件，放在自己项目静态资源目录下，彻底规避跨域问题（注意版权合规）
调试与验证要点
遇到拦截不要只看控制台报错，重点确认三点：
- 浏览器开发者工具 Network 标签页中，找到字体请求，查看 Response Headers 是否含
Access-Control-Allow-Origin - 检查字体 URL 是否真实发起（有些字体仅在实际使用时才加载，未渲染前不会触发请求）
- 若用 CDN，确认它是否透传源站响应头；很多 CDN 默认不缓存自定义 header，需单独开启“缓存响应头”功能
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
