web font loader 不优化字体引入，仅管理加载过程；真正影响体验的是协同控制 font-display、预连接和回调时机。
Web Font Loader 本身不优化字体“引入”，它只管理加载过程；真正影响体验的是你如何配合 font-display、预连接和回调时机做协同控制。单独用它反而容易引发 FOIT/FOUT 加剧或样式错乱。
为什么直接用 WebFont.load() 加载 Google Fonts 容易白屏或闪动？
浏览器默认对 @font-face 执行 FOIT（隐藏文本直到字体就绪），而 Web Font Loader 若未关闭自动 CSS 类注入，又会和 font-display: swap 的原生行为冲突——比如同时触发 wf-active 和 font-display: swap 的文本显示逻辑，导致两次重绘。
- 默认开启
classes: true，会往html元素加wf-active等类，但这些类的切换时机和浏览器原生font-display不同步 - 没显式声明
font-display: swap在 CSS 的@font-face规则里，Web Font Loader 的active回调就失去意义：你不知道字体“可用”和“已渲染”是否一致 - 在
active里直接改字体族（如body { font-family: 'Roboto' }），若此时页面已有内容，可能触发 layout shift
font-display: swap 必须手动写进 CSS，Web Font Loader 不会帮你加
这是最容易被忽略的前提。Web Font Loader 对 CSS 零修改，所有 @font-face 规则必须你自己定义，并显式带上 font-display: swap（或 optional）。
- 错误写法：
@font-face { font-family: 'Inter'; src: url('/fonts/inter.woff2'); }—— 没font-display，浏览器仍走 FOIT - 正确写法：
@font-face { font-family: 'Inter'; src: url('/fonts/inter.woff2'); font-display: swap; } - 如果用 Google Fonts，需手动生成带
font-display的链接，不能只靠 Web Font Loader 配置
用 active 回调做真正安全的样式升级，而不是“启用字体”
active 的作用不是“让字体生效”，而是“确认字体已加载并可安全用于增强场景”，比如动画、高亮、或替换 fallback 字体族而不闪动。
- 推荐做法：初始 CSS 中用系统字体 +
font-display: swap的自定义字体族，保证首屏立即可见 - 在
active里添加document.documentElement.classList.add('fonts-loaded')，然后用 CSS 规则升级排版细节：.fonts-loaded h1 { font-weight: 700; letter-spacing: -0.02em; } - 避免在
active中执行document.fonts.load()或强制重排，这会阻塞主线程
本地字体（custom 类型）加载失败的三个硬性条件
Web Font Loader 对本地字体几乎不做容错处理，失败往往卡在底层链路，不是配置问题。
- 服务器未返回正确的 MIME 类型（如
font/woff2），Chrome 会静默拒绝加载 -
custom.urls中的 CSS 文件路径是相对路径，但页面有<base href="/app/">，导致实际请求变成/app/path/to/myfont.css并 404 - 漏写
testStrings，Web Font Loader 无法验证字体是否真被应用（尤其在 Firefox 中），会一直停留在wf-loading状态
最关键的协同点在于：Web Font Loader 的 active 是“字体文件已下载并解析完成”的信号，不是“可以放心替换字体族”的信号；是否真能无感切换，取决于你 CSS 里 font-display 的取值、fallback 是否合理、以及有没有用 class 控制渐进增强而非暴力重写。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
