通过设置crossorigin: anonymous和配置服务器CORS响应头可解决图标字体跨域问题。具体需在@font-face中声明crossorigin: anonymous，确保服务端返回Access-Control-Allow-Origin等必要响应头，使浏览器以CORS模式正确加载外部域名下的字体资源，避免因同源策略导致的加载失败。
font-face中src跨域请求失败的典型表现
页面文字突然回退成系统默认字体，开发者工具 Network 面板里 @font-face 引用的 .woff2 或 .ttf 请求显示 CORS error 或状态码为 0，控制台报错类似 Access to font at 'https://cdn.example.com/fonts/icon.woff2' from origin 'https://your-site.com' has been blocked by CORS policy。这不是路径 404，而是浏览器主动拦截——即使文件真实存在且可直连访问。
link rel="stylesheet" 加 crossorigin 属性是否有效
无效。直接给加载 CSS 的 <link rel="stylesheet"> 标签加 crossorigin 属性，浏览器会忽略它。因为 crossorigin 只在以下场景生效：<link rel="preload" as="font">、<link rel="stylesheet">（仅当该 CSS 内部触发字体加载时，不作用于 link 本身）、或字体实际加载阶段由 CSS 引擎发起的子请求。真正需要加 crossorigin 的是字体资源被加载时的“源头行为”，而这个源头往往不可见——它藏在浏览器解析 @font-face 后自动发出的请求里，你无法直接控制。
所以正确做法是：
- 确保托管字体的服务器（如 CDN）返回响应头包含
Access-Control-Allow-Origin: *或精确域名 - 若使用
<link rel="preload" as="font">显式预加载字体，则必须加crossorigin="anonymous" - 避免在
<link rel="stylesheet">上硬加crossorigin，纯属无效操作
为什么 preconnect 到 fonts.gstatic.com 不能绕过 CORS
rel="preconnect" 只提前建立 TCP/TLS 连接，不发送任何字体数据，也不携带 Origin 头，因此完全不触发 CORS 校验。它解决的是网络延迟，不是权限问题。即便你已 <link rel="preconnect" href="https://fonts.gstatic.com">，只要字体文件响应头缺 Access-Control-Allow-Origin，照样加载失败。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
常见误判是：看到 preconnect 成功了，就以为字体能加载。其实两者属于不同协议层——preconnect 是网络层优化，CORS 是 HTTP 安全策略，互不替代。
本地开发时 localhost 加载远程字体总失败的根源
很多本地服务（如 Vite、Webpack Dev Server）默认不代理字体请求，也不注入 CORS 响应头。当你在 http://localhost:5173 页面里引用 https://cdn.example.com/font.woff2，浏览器按规则发起带 Origin: http://localhost:5173 的请求，但 CDN 返回的响应头若没允许该源（比如只写了 Access-Control-Allow-Origin: https://prod.example.com），就会失败。
临时解法（仅限调试）：
- 用插件（如 Chrome 的 CORS Unblocked）临时禁用同源策略（⚠️仅本地，勿用于 CI 或测试环境）
- 改用本地字体路径（
./fonts/xxx.woff2），避开跨域 - 在本地服务中配置反向代理，把
/fonts/*代理到 CDN，并手动添加响应头
真正可靠的方案，是让字体服务端始终返回兼容的 CORS 头——尤其注意 http://localhost 和 https://localhost 被视为不同源，需显式列出或使用 *。
