系统字体栈能跳过字体加载阻塞，因其不发起网络请求，所有字体均来自操作系统预装列表，font-family解析完毕即刻回退渲染，避免FOIT；常见表现为fonts.gstatic.com请求延迟、Lighthouse报错及首屏文字1–2秒后“弹出”。
系统字体栈为什么能跳过字体加载阻塞
浏览器遇到 @font-face 或 Google Fonts 的 @import 时，会暂停文本绘制，直到字体下载完成——这就是 FOIT（Flash of Invisible Text）。而系统字体栈不发起任何网络请求，所有字体名都来自操作系统预装列表，font-family 解析完立刻回退渲染，首屏文本零延迟。
常见错误现象：fonts.gstatic.com 请求排在 CSS 后面；Lighthouse 报 “Avoid invisible text while loading webfonts” 失败；页面首屏文字等 1–2 秒才“弹出”。
中英文混合场景下怎么写可靠的跨平台字体栈
不是“越全越好”，而是按平台优先级排列，确保每个系统至少命中一个本地字体。关键点：不加引号包裹带空格的字体名，否则 Safari 和旧版 Chrome 会解析失败。
-
-apple-system（macOS/iOS）优先于BlinkMacSystemFont，后者是 Chrome 旧别名，已可省略 -
"Segoe UI"错误写法 → 正确应为Segoe UI（无引号） - 中文必须分层：macOS 用
PingFang SC，Windows 用Microsoft YaHei，Android 用Roboto，Linux 用Ubuntu或DejaVu Sans - 末尾必须保留通用族名：
sans-serif，不能漏
推荐写法：font-family: -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Helvetica Neue, Arial, Noto Sans, PingFang SC, Microsoft YaHei, sans-serif;
立即学习“前端免费学习笔记（深入）”；
什么时候不该用系统字体栈
只在品牌强一致性要求的极少数位置才考虑自托管 WOFF2，比如 Logo、SaaS 产品主标题、或设计规范强制指定某款字重/字形的按钮文案。
正文、段落、列表、表单控件一律用系统栈——这不是妥协，而是对多数内容型页面最务实的选择。
容易踩的坑：
- 混合写法如 'Inter', -apple-system, ...：一旦 Inter 加载失败，后续系统字体不会自动兜底，必须靠完整逗号分隔链
- 给系统字体加引号（如 "Helvetica Neue"）：部分浏览器直接忽略该条目
- 忘记中文字体顺序：把 Microsoft YaHei 放在 PingFang SC 前面，会导致 macOS 用户看到模糊的微软雅黑渲染
font-display: swap 和系统字体栈能不能一起用
没必要。二者解决的是不同问题：font-display: swap 是为自托管字体设计的降级策略，而系统字体栈本身就没有加载过程。
如果你同时写了：@font-face { font-family: 'Custom'; src: url(x.woff2); font-display: swap; }
和body { font-family: 'Custom', -apple-system, ...; }
那实际效果取决于浏览器是否缓存了 Custom 字体——没缓存时仍要等首次下载，FOIT 风险未消除；缓存后才真正快。不如直接砍掉 @font-face，用纯系统栈更稳。
真正需要关注的，是那些你无法控制的第三方 CSS（比如某些 UI 组件库悄悄注入了 @font-face），它们可能偷偷触发字体请求——用 DevTools 的 Network 面板过滤 font，一眼就能揪出来。
