as="font"不加crossorigin会导致preload静默失效，浏览器完全忽略该预加载请求，Network面板无记录，字体无法进入专用缓存池，@font-face仍需重新发起CORS请求，FOIT持续。

as="font"不加crossorigin会导致preload静默失效

浏览器对字体预加载有硬性约束：只要写了as="font"，就必须同时存在crossorigin属性，否则整个<link rel="preload">会被忽略——Network 面板里根本看不到请求，也不会进字体缓存池，后续@font-face仍得重新发起带CORS头的请求。

这不是兼容性问题，而是规范强制行为。Chrome、Firefox、Safari 全部一致：漏掉crossorigin，就等于没写这条<link>。

• crossorigin是字体加载链路的“开关”，不是可选修饰
• 即使字体和HTML同源，也必须显式声明，浏览器不会自动补全或降级处理
• 不加时，浏览器退化为普通fetch，Priority显示为Low，Initiator是parser而非preload

crossorigin=""和crossorigin="anonymous"的区别在哪

二者在字体加载行为上完全等价，都触发匿名CORS模式（不发Cookie、不带认证凭据），但写法影响服务端兼容性。

推荐用crossorigin（无等号、无引号），这是W3C规范允许的合法空值语法，现代浏览器全部支持，且对服务端Access-Control-Allow-Origin响应头校验最宽松。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

立即学习“前端免费学习笔记（深入）”；

• crossorigin="anonymous"功能相同，但部分老旧CDN或自建服务端会因严格匹配响应头而拒绝
• crossorigin="use-credentials"几乎不该用——字体服务极少支持凭据传输，启用后大概率触发CORS错误
• 别写crossorigin不带值又不加引号的模糊写法（如crossorigin单独成属性），语义不清，构建工具可能误删

加了crossorigin但控制台还报CORS error怎么办

说明服务端没返回匹配的CORS响应头，不是前端代码问题。预加载请求能发出去，但字体引擎拒绝应用资源，因为跨域策略未通过校验。

• 检查服务端是否返回Access-Control-Allow-Origin: *（公共CDN）或Access-Control-Allow-Origin: https://yourdomain.com（私有域名）
• 确保响应头中不含Access-Control-Allow-Credentials: true（除非你真用了crossorigin="use-credentials"）
• 如果字体托管在第三方CDN，确认其文档是否明确支持字体跨域访问；有些CDN默认关闭字体CORS支持
• 注意：Access-Control-Allow-Origin: *和crossorigin="use-credentials"互斥，配错会导致静默失败

为什么as="font"必须搭配crossorigin才能复用到@font-face

浏览器把字体资源放进独立的font cache，但这个缓存池只接受CORS上下文下的响应。没crossorigin，资源就被丢进普通HTTP缓存，@font-face无法识别和复用，FOIT（Flash of Invisible Text）持续出现。

• 即使预加载路径和@font-face中src完全一致，没有CORS上下文，也不进字体缓存池
• 字体专用加载器（FontLoader）只在crossorigin存在时启用，负责高优先级调度、CORS请求头、字形数据校验
• 漏掉crossorigin，@font-face仍要重新发起一次带CORS头的请求，相当于白 preload 了一次

实际部署中最容易被忽略的点：不是“要不要加”，而是“加得对不对”——crossorigin必须出现在<link rel="preload" as="font">里，且服务端响应头必须同步匹配。两者缺一不可，单边配置等于没配。