真正有效的做法是组合使用 font-display: optional + 预加载关键子集字体 + 固定排版约束；因 font-display: swap 在移动端易致 FOUT 和布局抖动，而 optional 配合 ≤200KB 子集字体与 preload 才能稳定命中 100ms 加载窗口，再辅以显式尺寸约束防抖动。
移动端 @font-face 加载慢，光靠 font-display: swap 不够稳，尤其在中文字体场景下容易引发明显 FOUT 或布局抖动；真正有效的做法是组合使用 font-display: optional + 预加载关键子集字体 + 固定排版约束。
为什么 font-display: swap 在移动端经常失效
它确实能避免白屏（FOIT），但会强制浏览器用系统字体先渲染、等自定义字体加载完再替换——这对中文字体很危险：一个 2MB 的 WOFF2 文件在弱网下可能 3 秒才就绪，期间用户看到的是字号/行高完全不同的系统字体，文本块突然“撑开”或“收缩”，触发重排，尤其在 flex 容器里会错位甚至溢出。
更麻烦的是，iOS Safari 对 swap 的实现有延迟，有时替换动作卡在渲染队列末尾，造成肉眼可见的闪动。
- 不要在首屏文案多的页面无脑设
font-display: swap - 避免把
swap和未压缩的全量中文字体一起用 - 如果必须用
swap，至少配合font-size/line-height/height显式固定容器尺寸
应该优先用 font-display: optional 的真实条件
这个值告诉浏览器：“如果字体能在 100ms 内加载并就绪，就用它；否则直接跳过，全程用后备字体。” 它彻底规避了等待和替换，对移动端首屏体验最友好。
但它不是万能的——只有当字体文件足够小（≤200KB）、且已通过 提前拉取时，才大概率命中 100ms 窗口。
- 只对首屏必需的字重生效，比如
font-family: 'PingFang SC'; font-weight: 600;对应的粗体子集 - 必须搭配
as="font"和crossorigin使用 preload，否则无效： - 不能和多个
src格式并列写法混用，移动端解析开销高；单写url(...woff2)最稳妥
中文字体必须做子集化，否则 font-display 再好也救不了
一个完整思源黑体 Medium 就有 8MB+，即使用 optional，浏览器也会尝试加载——而 8MB 在 3G 网络下根本不可能 100ms 就绪，结果就是永远 fallback，等于白配。
子集化的关键是“只提取 HTML/CSS 中实际出现的汉字+标点+数字+ASCII 字母”，工具推荐 font-spider（Node.js 环境）或在线服务如 Transfonter 的 subset 功能。
- 运行前确保 HTML 中已写好所有首屏文案，比如
立即购买
- 子集字体必须包含常见标点（。！？“”‘’、；：…—）、阿拉伯数字和英文字母，否则用户输入搜索词时会回退失败
- 别信
unicode-range拆分中文——iOS Safari 解析不一致，U+4E00-U+9FFF在某些机型上直接忽略整条@font-face
加载完成后如何防止布局抖动
字体换上去那一刻，哪怕只是字宽差 0.5px，也可能让 display: flex 的按钮换行、grid-template-columns 的列宽突变。这不是 font-display 能解决的，得靠 CSS 主动约束。
核心是让后备字体和自定义字体在排版上“视觉等效”：用相同 font-size、显式 line-height、固定容器 height 或 min-height，必要时加 letter-spacing 微调。
- 对标题类元素，设
height: 1.5em（基于 line-height 计算）比只设line-height更稳 - 避免用
flex: 1包裹纯文本容器，改用min-width: 0防止内容撑开 - 如果用了动态加载全量字体（如用户滚动后加载），新文本渲染仍会抖动——此时只能接受，或提前预占位
子集字体体积、preload 时机、font-display 类型三者必须对齐，漏掉任一环，优化就打折扣。很多人调了 optional 却没做子集，结果还是 fallback；也有人做了子集却忘了 preload，浏览器压根没机会在 100ms 内就绪。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
