根本原因是浏览器对@font-face的src字体文件执行独立跨域检查，需同时满足CSS中声明crossorigin: anonymous和服务端返回Access-Control-Allow-Origin响应头。
为什么@font-face加载字体时触发CORS错误
根本原因不是CSS本身跨域，而是浏览器对@font-face中src指向的字体文件（如.woff2、.ttf）执行了独立的跨域检查。即使CSS成功加载，字体资源仍需单独通过CORS校验——缺一不可。
常见现象是控制台报错：Font from origin 'https://cdn.example.com' has been blocked from loading，或更具体的No 'Access-Control-Allow-Origin' header is present。注意：这个错误和CSS是否加crossorigin无关，它只影响字体请求本身。
-
@font-face不带crossorigin属性时，浏览器默认以“不透明”模式请求字体，服务端没配头就直接拦截 - 即使CSS文件所在域名和服务端一致，只要字体
src是另一个域名（比如CDN），就构成跨域 - 字体请求属于“简单请求”，不触发
OPTIONS预检，但必须收到Access-Control-Allow-Origin响应头才能被解析使用
如何让@font-face正确走CORS流程
必须在@font-face规则里显式声明crossorigin: anonymous（不能省略，也不能写错大小写）。这是唯一能让浏览器以CORS模式发起字体请求的方式。
示例写法：
@font-face {
font-family: 'IconFont';
src: url('https://cdn.example.com/fonts/icons.woff2') format('woff2');
font-display: swap;
crossorigin: anonymous;
}
- 不支持
crossorigin="use-credentials"写法，CSS规范只接受anonymous字面量 - 即使字体和页面同源，也建议加上
crossorigin: anonymous，避免未来迁移CDN时出问题 - 该声明仅对字体请求生效，不影响CSS文件本身的加载逻辑
服务端必须为字体文件返回正确响应头
光写crossorigin: anonymous没用。服务端必须针对字体后缀（.woff2、.woff、.ttf、.eot）单独配置响应头，且Access-Control-Allow-Origin不能依赖全局通配。
Nginx典型配置：
location ~* \.(woff2|woff|ttf|eot)$ {
add_header Access-Control-Allow-Origin "https://your-app.com";
add_header Vary "Origin";
expires 1y;
}
- 不要用
*配合Access-Control-Allow-Credentials: true（字体请求本身不带凭证，加了反而导致头冲突） - 必须加
Vary: Origin，否则CDN可能把A域的响应缓存后返回给B域，造成“明明配了却报错” - 确保该
location块匹配到字体路径，而不是只配在/api/或根路径下
为什么@import引入含字体的CSS会彻底失败
@import无法声明crossorigin，也不触发任何CORS协商。浏览器把它当做一个“不透明样式表”，即使其中@font-face写了crossorigin: anonymous，字体请求仍会被降级处理，服务端头再全也没用。
- Network面板能看到字体请求返回200，但字体就是不渲染——内容被CSS引擎静默丢弃
- 控制台错误信息和手动
fetch字体结果一致，但无法调试或捕获 - 唯一可靠方案是改用
并设置crossorigin，让整个加载链路可控
最容易被忽略的一点：字体CORS失败不会阻塞页面渲染，也不会让CSS文件加载报错，你可能只发现图标空白、文字回退成系统字体——这种“静默失效”比红字报错更难定位。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
