font-display: swap是多数场景起点，但必须写在@font-face内部、拼写正确、每个字重单独声明，并配合preload+crossorigin及合理fallback链，否则失效导致白屏。
font-display 不是“加不加”的问题，而是“加错就等于没加”——写错位置、拼错值、漏掉 preload，都会让 swap 失效，首屏照样白屏 3 秒。
font-display 必须写在 @font-face 内部，且紧挨 src 后
浏览器只认 @font-face 规则里的 font-display，写在 body、:root 或全局样式里完全无效。更常见的是拼写错误：swop、"swap"、swap: 都会导致整条 @font-face 被忽略，连 fallback 字体都出不来。
- 正确写法示例：
@font-face { font-family: 'Inter'; src: url('inter.woff2') format('woff2'); font-display: swap; } - 同一字体族的
font-weight: 400和font-weight: 700必须各自声明独立的@font-face，不能只给 Regular 加font-display就指望 Bold 也生效 - 中文字体尤其要注意：HarmonyOS Sans、思源黑体等常含多个字重，漏声明某一个，对应文本就会回退失败或渲染异常
swap 是多数场景起点，但不是万能解药
font-display: swap 的逻辑是“立刻用 font-family 回退链第一个可用系统字体撑开布局，加载完再替换”。它解决 FOIT（字体加载期间空白），但可能引发 FOUT（字体替换时的布局偏移）。
- 若 WOFF2 文件 >1.5MB（常见于未子集的中文字体），替换延迟明显，用户会看到文字先细后粗地跳一下
- 回退链必须合理，例如：
font-family: 'Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;，避免在旧版 Android 上 fallback 到过粗的 Droid Sans - 在 iOS Safari 16.4 之前，
swap对某些 variable font 的支持不稳定，建议搭配@supports (font-variation-settings: normal)做降级
preload + crossorigin 是 swap 发挥作用的前提
font-display 控制“怎么显示”， 才决定“什么时候开始加载”。没预加载，swap 的“立刻显示”就只是用系统字体硬撑，自定义字体可能到用户滚动后才发起请求。
- 必须写在所有
之前，否则浏览器可能已触发重复请求 - 必须带
crossorigin属性，否则跨域字体（如 CDN 或 Google Fonts）预加载失败，后续@font-face也会因 CORS 报错而失效 -
as="font"不可省略，否则浏览器按普通资源 fetch，失去高优先级；写成as="style"或as="script"同样无效 - 示例：
<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
fallback 比 swap 更适合移动端关键文本
对正文、按钮、表单标签这类用户必须读取的内容，font-display: fallback 往往比 swap 更稳。它让浏览器在约 500ms 内尝试加载，超时即永久降级，既避免长白屏，也规避了大字体加载完后的突兀替换。
- 中文字体体积大，
swap在弱网下容易造成“先显示再跳变”，而fallback直接放弃加载，视觉更一致 - iOS Safari 对
swap的替换时机控制较松，有时会延迟触发重绘；fallback行为更确定 - 注意：
fallback不代表“不加载”，它仍会异步加载字体供后续使用（比如用户放大页面、切换主题）
真正难的不是选哪个值，而是每个字重单独声明、每条 preload 都带 crossorigin、每个 font-family 回退链都经真机测试——这些细节一漏，优化就归零。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
