根本原因是浏览器未将preload请求识别为字体：as="font"缺失、crossorigin漏写或href与@font-face的src路径不一致，任一错误均导致预加载失效，initiator显示parser、priority为low或请求被cancelled。
为什么字体 preload 写了但 FOIT/FOUT 还在
根本原因不是没写 rel="preload"，而是浏览器压根没把它当字体用——as="font" 缺失、crossorigin 漏掉、或 href 和 @font-face 中的 src 路径不一致，三者任一出错，预加载就形同虚设。
常见现象：Network 面板里字体请求 Initiator 显示 parser 而非 preload，Priority 是 Low，甚至 Status 为 cancelled。这不是缓存问题，是浏览器从一开始就没按字体逻辑处理这个请求。
-
as="font"必须显式声明，写成as="woff2"或留空，浏览器直接降级为普通 fetch -
crossorigin属性必须存在（值可为空），哪怕字体和 HTML 同源——字体加载默认走匿名 CORS 模式，缺它就丢弃已下载内容 -
href必须和@font-face的src完全一致：包括协议、域名、路径、查询参数（如?v=2.1），差一个字符就无法复用缓存
字体 preload 的最小可行配置怎么写
不是越全越好，而是刚好够用。以下是最简且可靠的写法，适用于 WOFF2 字体：
<link rel="preload" as="font" type="font/woff2" crossorigin href="/fonts/inter-bold.woff2">
对应 CSS 中必须有匹配的 @font-face：
@font-face {
font-family: 'Inter';
font-weight: 700;
src: url('/fonts/inter-bold.woff2') format('woff2');
}
-
type="font/woff2"推荐带上，避免 MIME 类型探测失败；服务端返回的 Content-Type 必须与之匹配 - 不要加
onload或其他 JS 控制逻辑——字体不需要“激活”，只要@font-face注册成功且文本用到该字体，浏览器会自动从缓存取 - 如果用了 CDN，
href必须带完整域名（如https://cdn.example.com/fonts/...），不能只写相对路径
哪些字体不该 preload
预加载不是“所有字重都来一遍”的保险操作，而是精准狙击首屏实际渲染所用的变体。多 preload 一个文件，就多占一次 TCP 连接、多耗一次带宽、多挤占真正关键资源的优先级。
- 只 preload 首屏立即用到的组合：比如正文用
font-weight: 400，标题用font-weight: 700，那就只 preload 这两个 WOFF2 文件 - 避免 preload
italic、light、thin等未在首屏 CSS 中出现的变体——它们可能永远不被触发 - 不要为 Google Fonts 的全套
family=Inter:wght@100..900做批量 preload，拆解成单个href并只选真实用到的权重 - 动态生成的字体 URL（如带时间戳或哈希）必须和
@font-face保持完全一致，否则缓存无法命中
怎么确认字体 preload 真生效了
别信代码写了，要看 Network 面板里那个请求是不是真被浏览器当回事儿。重点盯三列：Initiator、Priority、Time。
- 筛选条件设为
type: font，再按Initiator列找preload—— 如果是parser或script，说明没走预加载路径 -
Priority应为Highest（Chrome）或High（Firefox），不是Low；Low意味着as错了或缺失 - 对比未加 preload 时的 Start Time：理想情况应提前 200–600ms 发起，尤其在弱网下更明显；如果 Time 没变化，大概率是路径不一致或服务端 CORS 头没配（
Access-Control-Allow-Origin: *） - 静默失效最难排查：Headers 标签页里看
Accept请求头是否为font/woff2，响应头Content-Type是否匹配，不匹配就不会复用
最易被忽略的是：服务端返回 302 重定向或 Cache-Control: no-store，会导致预加载结果无法用于后续渲染——这种失效不会报错，只表现为反复下载。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
