图标显示为方块或问号，大概率是字体文件被浏览器静默拦截，根本原因是@font-face加载woff2/woff/ttf时触发跨域限制；需检查Network中font请求状态、CDN是否配置Access-Control-Allow-Origin响应头、@font-face是否声明crossorigin: anonymous，或改用base64内嵌兜底。
直接用 CDN 引入字体图标 CSS 文件，但图标显示为方块或问号，大概率不是网络没通，而是字体文件被浏览器静默拦截了——根本原因是 @font-face 加载的 woff2/woff/ttf 文件触发了跨域限制。
检查 font 请求是否被拦在 Network 面板里
打开 DevTools → Network → 筛选 font，重点看 woff2 请求的状态：
- 如果状态是
403或blocked:mixed-content，说明 CDN 没配 CORS 或协议不一致（比如 http 页面加载 https 字体） - 如果请求发出去了但响应头里没有
Access-Control-Allow-Origin，浏览器就会丢弃字体数据，不报错但不渲染 - 注意：部分 CDN（如早期 cdn.jsdelivr.net）对 font 文件路径有缓存误判，加
?v=1能绕过
CDN 侧必须返回正确的 CORS 响应头
字体文件所在的 CDN 域名，必须在响应中带上 Access-Control-Allow-Origin。这不是前端能改的，得去 CDN 控制台配：
- 腾讯云 COS + CDN：进 COS「跨域访问 CORS 设置」添加规则，Origin 填你网站域名；再进 CDN「高级配置 → 添加 HTTP Header」，参数填
Access-Control-Allow-Origin，值填https://yourdomain.com（别用*，除非你明确允许凭证携带） - 阿里云 CDN：在「HTTP 头设置」里添加同名 Header，值同上；注意配置后要手动「刷新缓存」，否则旧响应头还在生效
- jsDelivr：默认支持字体跨域，但若用自定义域名托管字体，仍需自己配 CORS
前端 @font-face 必须声明 crossorigin: anonymous
即使 CDN 已配好 CORS，前端 CSS 里的 @font-face 规则也得显式加上这个属性，否则浏览器可能以非 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，最安全也最常用 - 如果漏掉这一行，哪怕服务器返回了正确 header，字体依然加载失败
- 某些图标库生成的 CSS（如 iconfont.cn 下载的）默认不带这行，得手动补上
实在搞不定 CORS？用 base64 内嵌字体是最稳的兜底方案
当 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 面板重新触发 font 请求。
