当字体图标无法正常加载，在页面上呈现为方块或问号时，不必急于怀疑网络连接问题。多数情况下，页面本身可以正常打开，字体资源的请求也未出现 404 错误——核心原因在于浏览器静默拦截了字体文件。问题根源通常在于，通过@font-face加载 woff2、woff 或 ttf 格式时触发了跨域限制。下面将逐一梳理排查方向，帮助您快速定位并解决。
首先明确排查起点：打开开发者工具的 Network 面板，筛选 font 类型的请求，重点观察 woff2 请求的状态码。如果显示 403 或 blocked:mixed-content，通常意味着 CDN 未配置 CORS，或者协议不一致——例如 HTTP 页面去请求 HTTPS 下的字体资源。即便请求已成功发出，若响应头中缺少 Access-Control-Allow-Origin，浏览器依然会丢弃字体数据，不报错但也不渲染。有一个容易被忽略的细节：部分 CDN 对字体文件路径存在缓存误判（如早期版本的 cdn.jsdelivr.net），此时在路径后添加 ?v=1 参数通常可以绕过该问题。
接下来检查 CDN 侧配置。托管字体文件的 CDN 域名必须在响应中包含 Access-Control-Allow-Origin 头部，这属于后端配置，前端无法更改。具体操作上，以腾讯云 COS 搭配 CDN 为例：先进入 COS 的“跨域访问 CORS 设置”，添加一条规则，Origin 填入您的网站域名；再前往 CDN 的“高级配置 → 添加 HTTP Header”，参数设为 Access-Control-Allow-Origin，值填入您的域名（建议避免使用 *，除非明确需要允许携带凭证）。阿里云 CDN 则在“HTTP 头设置”中添加同名 Header。配置完成后务必手动刷新缓存，否则旧的响应头可能仍然生效。jsDelivr 默认支持字体跨域，但如果您使用自定义域名托管字体，仍需自行配置。
即便 CDN 已正确配置 CORS，前端 CSS 中的 @font-face 规则也必须显式声明 crossorigin: anonymous。这一步极易被遗漏——缺少该声明时，浏览器可能以非 CORS 模式发起请求，导致服务端的 Access-Control-Allow-Origin 失效。具体配置示例如下：
@font-face {
font-family: 'iconfont';
src: url('https://cdn.example.com/iconfont.woff2') format('woff2');
crossorigin: anonymous; /* 关键！不能少 */
}
crossorigin: anonymous 表示不携带 Cookie，安全性最高且适用最广。若遗漏该属性，字体加载依然失败。特别提醒：部分图标库（如 iconfont.cn）生成的 CSS 默认不包含此行，需要手动补充。
最后考虑兜底方案。当 CDN 不可控、运维不配合，或项目中仅使用少量图标时，将字体转换为 base64 直接嵌入 CSS 是最稳妥的落地方式。使用 transfonter.org 上传字体文件，勾选 “Base64 encode”，下载后仅保留 CSS 中的 data:application/x-font-woff2;base64,... 部分。替换原 @font-face 中所有 url(...)，仅保留 base64 版本，格式类似 src: url('data:application/x-font-woff2;base64,...') format('woff2');。缺点在于 CSS 文件体积会增大——woff2 本身压缩率较高，base64 后体积大约增加 33%，但彻底避免了跨域与请求链路问题。
有一条容易被忽视的规则：CORS 配置生效 ≠ 字体立即可用。CDN 缓存、浏览器缓存甚至本地 Service Worker 都可能保留旧的响应头。每次修改配置后，务必执行硬刷新（Ctrl+Shift+R），并清空 Network 面板重新触发字体请求，才能确认新配置是否真正生效。
