HTML中link标签的crossorigin属性对字体跨域加载的影响-html教程-PHP中文网

必须加crossorigin属性，否则字体preload静默失效；浏览器强制要求该属性触发fontloader专用通道，启用高优先级、cors请求头及独立字体缓存池，即使同源也必须显式声明。

html中link标签的crossorigin属性对字体跨域加载的影响

漏掉 crossorigin，<link rel="preload" as="font"> 就等于没写——Network 面板里根本看不到请求，或者能看到但状态码为 0，@font-face 仍要重新发起带 CORS 头的请求。这不是加载慢，是加载链路被浏览器直接掐断。

原因在于：字体资源在预加载阶段必须进入 FontLoader 专用通道，而该通道的触发开关就是 crossorigin 属性。哪怕字体和 HTML 同源，也必须显式声明，浏览器才启用高优先级、CORS 请求头、独立 font 缓存池。

crossorigin（空值语法）最稳妥，所有现代浏览器支持，服务端 CORS 头校验最宽松
crossorigin="anonymous" 功能等价，但部分老旧 CDN 会因严格匹配 Access-Control-Allow-Origin 响应头而拒绝
crossorigin="use-credentials" 几乎不该用——字体服务极少需要 Cookie，启用后大概率触发预检失败或 CORS 错误

只写 as="font" 不加 crossorigin，浏览器仍当普通资源下载（Priority 显示为 Low，Initiator 是 parser 而非 preload），不走 FontLoader，@font-face 无法复用预加载结果，FOIT 持续。

反过来，只加 crossorigin 但没写 as="font"，浏览器根本不会按字体逻辑处理，href 指向 .woff2 也没用——它可能被当成 script 或 style 下载，最终被丢弃或阻塞渲染。

crossorigin 写对只是第一步；控制台报 CORS error，说明服务端没返回匹配的响应头，不是前端代码问题。

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

关键响应头只有两个：

公共 CDN：必须返回 Access-Control-Allow-Origin: *
私有域名：必须返回 Access-Control-Allow-Origin: https://yourdomain.com（不能是 *，尤其当你用了 crossorigin="use-credentials"）
绝对不要返回 Access-Control-Allow-Credentials: true，除非你真在用 crossorigin="use-credentials"

如果字体托管在第三方 CDN，务必查其文档是否明确支持字体跨域访问——有些 CDN 默认关闭字体 CORS 支持，需单独开通。

给 <link rel="stylesheet"> 标签加 crossorigin，浏览器会直接忽略。它对字体加载不起作用，因为字体实际加载是由 CSS 解析器在遇到 @font-face 时发起的子请求，源头不在 link 标签本身。

常见误判是：看到 CSS 加载成功，就以为字体也好了。其实字体请求是独立的、隐藏的，且必须满足自己的 CORS 条件。

真正该盯住的是：<link rel="preload" as="font"> 的写法 + 字体服务端响应头
<link rel="preconnect"> 到 fonts.gstatic.com 等域名只能优化连接建立，不解决 CORS，不能替代 crossorigin
图标字体（如 iconfont）同样适用这套规则，@font-face src 跨域失败的表现就是文字回退成系统字体，Network 面板里对应 .woff2 请求显示 CORS error 或状态码为 0

字体加载的 CORS 链路极短但极刚性：前端少一个 crossorigin，服务端少一个响应头，整个预加载就归零。最容易被忽略的是「同源也不自动绕过」这个点——开发者常以为自己域名下的字体不用管 CORS，结果 FOIT 一直持续，却在 Network 面板里找不到预加载请求。