选 fallback 最不闪：500ms 内用系统字体渲染，超时放弃加载，兼顾首屏可见性与加载可控性；swap 在弱网下易致长时间空白，optional 则可能因字重缺失导致渲染异常。
font-display 属性值选哪个才不闪？
字体加载时的“FOIT（Flash of Invisible Text）”或“FOUT（Flash of Unstyled Text）”问题，本质是 font-display 值没对上业务场景。不是越快越好，也不是默认最稳。
常见错误：直接写 font-display: swap 就以为万事大吉，结果在弱网下首屏文字长时间空白（尤其 iOS Safari 对 swap 的实现更激进）；或者用 block 导致关键文案延迟渲染，影响可读性。
-
swap：适合品牌字体、非核心排版——文字立刻用系统字体撑开，等自定义字体就绪再替换。但注意：若字体加载失败，系统字体会一直显示，且无回退提示 -
fallback：推荐多数 Web 应用——500ms 内用系统字体渲染，超时后放弃加载，避免阻塞布局流。比swap更可控 -
optional：适合非关键字体（如装饰性 icon font），浏览器可跳过加载。但不保证一定加载，连带影响@font-face中的font-weight解析逻辑
font-display 在 @font-face 里怎么写才生效？
必须写在 @font-face 规则内部，且只对当前字体声明起作用。外层 CSS 或全局设置无效，也不能通过 JS 动态修改。
容易踩的坑：把 font-display 当成通用 CSS 属性写在 body 或 html 上，完全不起作用；或者多个 @font-face 声明共用同一 font-family 名但没各自配 font-display，导致部分字重失效。
立即学习“前端免费学习笔记（深入）”；
```css
@font-face {
font-family: "Inter";
src: url("/fonts/inter-regular.woff2") format("woff2");
font-weight: 400;
font-display: fallback; /* ✅ 必须在这里 */
}
```font-display 影响 font-weight 和 font-style 匹配吗？
会影响。当浏览器找不到精确匹配的 @font-face（比如只声明了 font-weight: 400，但用了 font-weight: 500），它会尝试“合成粗体”，而 font-display 的行为会干扰这个过程。
典型现象：设了 font-display: optional 后，font-weight: 600 文字突然变细、模糊，甚至回退到系统字体——因为浏览器跳过了加载，又没找到对应字重的声明，只能合成或降级。
- 确保每个需要的
font-weight/font-style组合都有独立的@font-face声明 - 不要依赖浏览器自动映射；
optional下尤其要避免缺失字重 - 用
font-display: fallback比optional更稳妥，它至少保障基础字重加载窗口期
如何验证 font-display 实际生效了？
不能只看 DevTools 的“Fonts”面板——它只显示已加载字体，不反映加载策略。得看网络请求时机和文本渲染行为。
实操建议：
- 在 Network 面板过滤
font，勾选 “Disable cache”，刷新页面，观察字体请求是否被推迟（fallback下应有 ~500ms 延迟） - 用
document.fonts.load()+performance.now()手动测加载耗时，注意：该 API 不受font-display控制，它只管下载完成，不管渲染时机 - 真机测试 iOS Safari：它对
swap的“隐形期”更长，且不触发fontloading事件，容易误判
最易被忽略的是字体加载失败后的兜底行为——font-display 不提供错误回调，得靠 document.fonts.check() 或 MutationObserver 监听 DOM 文本变化来间接判断是否卡在不可见状态。
