根本原因是字体文件加载被cors拦截或路径解析失败；@font-face中url()路径错误导致404，或cdn未返回access-control-allow-origin响应头引发cors错误，而link标签加crossorigin属性无效。
直接用 <link rel="stylesheet"> 引入第三方字体 CSS（如 Font Awesome、Iconfont）时，图标显示为空白或方块，**根本原因不是 HTML 写错了，而是字体文件加载被 CORS 拦截或路径解析失败**。浏览器已发出请求，但要么 404，要么返回了 CORS error，@font-face 无法加载字形数据。
为什么加 crossorigin 到 link rel="stylesheet" 没用
这是最常踩的坑：给 <link rel="stylesheet" href="https://cdn.example.com/iconfont.css"> 加 crossorigin="anonymous"，浏览器会直接忽略该属性——它对样式表加载本身不生效。
-
crossorigin只在<link rel="preload" as="font">或 JS 动态读取document.styleSheets时起作用 - 真正触发字体请求的是 CSS 里的
@font-face规则，而这个子请求是否走 CORS，取决于服务端响应头，不是<link>标签有没有写crossorigin - 你看到 Network 面板里
.woff2请求报 CORS 错误，问题出在 CDN 服务器没返回Access-Control-Allow-Origin，不是前端<link>少写了什么
检查字体文件是否真的能被加载
打开浏览器开发者工具 → Network → 过滤 woff2 或 woff，看对应字体请求的状态码和响应头：
- 状态码
404：说明@font-face中的url()路径解析错误，比如相对路径url('./iconfont.woff2')被当成页面当前 URL 的同级路径，而非 CDN 域名下路径 - 状态码
0或控制台报Blocked by CORS policy：服务端缺失Access-Control-Allow-Origin: *（或精确域名） - 请求发出去了但字体没生效：确认
@font-face声明的font-family名与你在 HTML 中使用的类名（如class="iconfont icon-home"）所依赖的字体族一致
三种真正有效的解决路径
别在 <link rel="stylesheet"> 上硬加 crossorigin，试试下面这些实操方案：
- 用
<link rel="preload" as="font">显式预加载字体，并**必须加crossorigin="anonymous"**：<link rel="preload" as="font" href="https://cdn.example.com/iconfont.woff2" crossorigin="anonymous">
注意：href必须和@font-face中src的 URL 字符串完全一致（含大小写、查询参数），否则浏览器不复用预加载资源 - 换用 base64 内联字体：用工具（如 transfonter.org）把字体转成 base64，嵌入 CSS 文件中。这样彻底规避跨域，但文件体积变大，适合图标少、更新不频繁的场景
- 改用 JS 加载方式（如 Font Awesome 官方推荐）：
<script src="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.0/js/all.min.js"></script>
JS 方式可动态注入@font-face并控制加载时机，对 CDN 配置宽容度更高
容易被忽略的关键点
字体加载失败往往不是单点问题，而是链路断裂：CDN 未发布 Iconfont 项目、@font-face 的 url() 是相对路径却托管在跨域 CDN、服务端 CORS 响应头漏配、甚至构建工具（如 Vite/Webpack）注入的 <link> 默认不带 crossorigin —— 这些都得逐层验证。尤其注意，preconnect 和 dns-prefetch 对字体 CORS 问题毫无帮助，它们只优化连接建立，不解决权限校验。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
