WebFont Loader 是一个 JavaScript 库，用于主动管理字体加载过程，解决 FOIT/FOUT 失控问题，但不提升加载速度；它需与 font-display: swap 配合使用，通过 active 回调获知字体就绪时机，避免样式错乱。
WebFont Loader 是什么，它真能解决字体阻塞问题？
WebFont Loader 本身不提升字体加载速度，但它能精准控制字体加载时机和行为，避免浏览器默认的“隐藏文本直到字体就绪”（FOIT）或“闪动”（FOUT）失控。关键在于它把字体加载从 CSS 的被动触发，变成 JS 主动管理，从而让开发者能监听状态、降级回退、配合字体显示策略（font-display）协同工作。
如何用 WebFont Loader 配合 font-display: swap 避免 FOIT？
单独用 font-display: swap 能让文本立即显示后备字体，但无法知道自定义字体何时真正可用；WebFont Loader 则通过 active 回调告诉你“字体已加载并可安全使用”。二者必须配合，否则容易出现样式错乱或重复重绘。
- 在 CSS 中为
@font-face显式声明font-display: swap（不是靠 WebFont Loader 自动加） - 在 WebFont Loader 配置中关闭
classes: true（默认会加wf-active等 class，与font-display: swap的原生行为冲突） - 改用回调函数处理字体就绪：在
active中移除 loading 状态、启用动画、或切换字体族
WebFont.load({
google: { families: ['Inter'] },
active: () => document.documentElement.classList.add('fonts-loaded'),
inactive: () => document.documentElement.classList.add('fonts-failed')
});
为什么直接用 WebFont.load() 加载本地字体容易失败？
WebFont Loader 对本地字体（custom 类型）只做简单 script 注入或 CSS 插入，不处理 CORS、MIME 类型、字体格式兼容性等细节。常见报错如 Failed to load resource: net::ERR_BLOCKED_BY_CLIENT 或字体始终不渲染，往往是因为：
- 字体文件路径未被服务器正确配置 MIME 类型（如
font/woff2） - 使用了相对路径但页面 URL 有 base href，导致路径解析错误
- 未在
custom配置中显式指定urls数组，或漏写testStrings导致检测失败 - 多个
@font-face规则中font-weight/font-style值与实际字体元数据不一致，造成匹配失败
WebFont Loader 在现代项目里还有必要吗？
如果项目已用 font-display: optional + preload + IntersectionObserver 懒加载字体，那 WebFont Loader 多数功能已被原生能力覆盖。但它仍有不可替代的场景：
立即学习“前端免费学习笔记（深入）”；
- 需要兼容 IE9–11（
font-display完全不支持） - 需统一管理 Google Fonts、Typekit、本地字体三类来源，并共享加载状态
- 依赖
loading/active/inactive精确生命周期做 UI 反馈（比如骨架屏持续时间依赖字体加载完成）
注意：它的 timeout 参数默认 5 秒，但这个超时是针对整个加载流程，不是单个字体——如果配置了多个字体族，一个失败就会触发 inactive，容易误判。
