不推荐在生产环境主样式表中用 @import 引入 Google Fonts，因其阻塞 CSS 解析、拖慢渲染、引发 FOIT；应改用 配合 preconnect、preload 和 swap 策略优化加载。
直接用 @import 在 CSS 里引入 Google Fonts 是否可靠？
不推荐在生产环境的主样式表中用 @import 引入 Google Fonts。它会阻塞 CSS 解析，拖慢页面渲染，尤其在移动端或弱网下明显卡顿。
常见错误现象：@import url('https://fonts.googleapis.com/css2?family=Inter&display=swap'); 写在 style.css 开头，结果首屏文字闪动、FOIT（Flash of Invisible Text）持续数秒。
- 浏览器必须先下载并解析完这个外部 CSS，才能继续处理后续规则
- Google Fonts 的
css2地址本身带重定向和缓存策略，多一层网络不确定性 - 无法与本地 CSS 合并压缩，不利于构建流程
更稳妥的做法：用 <link> 标签提前加载
把字体加载逻辑从 CSS 剥离，交给 HTML 的 ，利用浏览器预加载机制提前发起请求。
使用场景：所有需要稳定控制字体加载时机的项目，尤其是 SSR 或静态站点。
立即学习“前端免费学习笔记（深入）”；
- 加上
rel="preconnect"减少 DNS 和 TLS 开销：<link rel="preconnect" href="https://fonts.googleapis.com"> - 再加
rel="preload"提升优先级（注意只对font类型有效，且需指定as="font"和type） - 最终用
<link rel="stylesheet">加载字体 CSS，确保样式及时生效
示例片段：
<link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Inter:wght@400;500;700&display=swap">
display 参数选 swap 还是 optional？
这决定字体加载失败或延迟时的回退行为，直接影响用户体验和 LCP 指标。
参数差异：
-
swap：立即用系统字体渲染，等 Web 字体就绪后替换——有 FOUT（Flash of Unstyled Text），但可读性优先 -
optional：只在字体能快速加载（通常 100ms 内）时才用；否则全程用后备字体——无闪动，但可能永远不用 Web 字体 -
block：等字体加载完成才显示文字——FOIT 风险高，LCP 易超标
建议多数情况用 swap，除非你明确接受“部分用户看不到定制字体”这个权衡。
字体文件实际加载了没？怎么验证？
别只看 <link> 写对了，得确认字体真的进了渲染管线。
容易踩的坑：
- Chrome DevTools 的
Network标签页里搜.woff2，但 Google Fonts 返回的是 CSS，字体文件地址藏在其中——得点开那个css2请求，看响应体里的src: url(...) - 字体加载成功后，
Computed面板里查元素的font-family，看是否匹配到local(...)或url(...) - 如果用了
font-display: swap却没看到 FOUT，可能是字体已缓存，试试无痕窗口或禁用缓存刷新
真正复杂的是字体加载与 JS 渲染时序的耦合——比如用 document.fonts.load() 做主动检测时，得注意跨域限制和 Promise 状态管理。
