移动端字体加载白屏或闪动的核心原因是浏览器阻塞渲染，应采用子集化+font-display:optional+固定排版的组合策略：提取首屏汉字生成≤200KB子集字体，preload关键WOFF2文件，为文本元素显式设置font-size/line-height/height以避免布局抖动。
移动端字体加载慢，@font-face 为什么经常白屏或闪动
核心问题不是 @font-face 写得不对，而是浏览器在移动端默认「阻塞渲染」直到字体加载完成（尤其是 iOS Safari 和 Android Chrome 的较旧版本）。用户看到空白或系统字体突然跳变成自定义字体，本质是字体加载时机没控制好。
关键点：移动端网络波动大、首屏资源竞争激烈，不能依赖 font-display: swap 一招鲜——它虽能避免白屏，但可能引发明显 FOIT/FOUT，尤其在中文字体（几 MB）场景下。
-
font-display: optional更适合移动端：浏览器只在字体能在 100ms 内就绪时使用，否则直接用后备字体，彻底规避加载等待 - 务必配合
preload提前拉取关键字体文件（如标题用的粗体），但仅限 WOFF2 格式，且只 preload 首屏必需的字重/样式，别 preload 全套 - 避免在
@font-face中声明多个src并列（如同时写 WOFF2 + WOFF + TTF），移动端解析开销高；优先单写url(...woff2)，让不支持的旧设备回退到系统字体更干脆
中文字体太大，怎么按需加载字符集
一个完整中文字体文件常超 2MB，移动端 3G 网络下加载耗时可能达数秒。直接上 @font-face 加载全量字体等于主动放弃首屏体验。
可行方案是「子集化 + 动态加载」：用工具（如 fontmin 或在线服务）提取页面实际用到的汉字（比如只含“首页”“立即购买”等文案），生成小体积子集字体（通常 ≤ 200KB）。
立即学习“前端免费学习笔记（深入）”；
- 子集字体必须保留常用标点、数字、英文字母，否则遇到用户输入或动态文案会回退失败
- 不要用 CSS
unicode-range拆分中文字体——浏览器对中文 Unicode 区间解析不一致，iOS Safari 尤其不可靠 - 若需支持搜索框输入、评论等动态内容，建议用「基础子集 + 异步加载全量字体」策略：先显示子集字体，待空闲时再 fetch 全量字体并注入
@font-face，后续新渲染文本自动生效
字体加载完成后如何避免布局抖动
即使字体加载成功，不同字体的 line-height、letter-spacing、字宽差异仍会导致 DOM 元素尺寸突变，触发重排（reflow），尤其在 flex/grid 布局中容易撑开容器或错位。
最有效方式不是调参数去“拟合”，而是从根上隔离影响：
- 为使用自定义字体的元素显式设置
font-size、line-height、height（固定值或em），避免依赖字体度量自动计算 - 用
size-adjust（Chrome 106+ / Safari 17+ 支持）微调字体缩放比例，使子集字体视觉高度尽量贴近原字体，但注意它不解决宽度问题 - 禁用
font-optical-sizing: auto：移动端字体引擎对此支持差，开启后反而加剧渲染不一致
调试字体是否真被加载和使用
光看 DevTools 的 Network 面板不够——文件下载完成 ≠ 字体被应用。真实判断依据是元素 computed style 中的 font-family 是否显示为你声明的字体名，以及 font-style/font-weight 是否匹配。
快速验证步骤：
- 在 Elements 面板选中目标文本节点，展开 Styles → 查看
font-family计算值，确认是否为你的自定义字体名（而非回退的sans-serif） - 执行
document.fonts.check('16px "YourFontName"')：返回true表示字体已加载且可用；若为false，再查document.fonts.load('16px "YourFontName"')是否 resolve - 监听
fontfaceobserver库的失败回调时，注意它可能把timeout误判为加载失败——实际是字体已加载但未激活，建议改用原生document.fontsAPI
移动端字体优化没有银弹，真正起效的是组合策略：子集化控体积 + optional 控时机 + 固定排版控抖动。最容易被忽略的是——别假设用户会等字体加载完才开始阅读，他们早就在滑动了。
