会，字体加载慢的根源是策略不当导致foit/foft和cls，关键在font-display配置、preload方式及路径可靠性；font-display:swap误用引发foft，因浏览器合成字重造成视觉突变。
会，但不是字体本身拖慢加载，而是加载策略不当导致闪烁（FOIT/FOFT）和布局偏移（CLS）。关键在 font-display 配置、预加载方式和资源路径是否可靠。
font-display: swap 为什么常被误用？
很多人以为加了 font-display: swap 就万事大吉，结果页面文字先闪出系统字体，再跳回自定义字体——这叫 FOFT（Flash of Faux Text），本质是字体文件加载完成前用了浏览器合成的粗/斜体，造成视觉突变。
-
swap适合对可读性要求高、能接受短暂样式不一致的场景；但若字体字重不全（比如只引入了 Regular，没引入 Bold），浏览器会强行模拟，触发重排+重绘 -
block会隐藏文字 3s（Chrome 默认），超时后才 fallback，适合品牌展示页，但需配合document.fonts.load()主动控制显示时机 -
optional最激进：仅当字体已缓存才使用，否则全程用系统字体，几乎零闪烁，但牺牲设计一致性
preload 字体但还是卡？检查这三个地方
<link rel="preload"> 不是万能钥匙。如果预加载失败或未命中，浏览器照样走默认加载流程，该闪还闪。
- 路径必须绝对准确：
href="/fonts/inter-var-latin.woff2"和实际服务器返回的路径大小写、扩展名、斜杠方向必须完全一致（file:// 协议下尤其敏感） - 必须声明
as="font"和type="font/woff2"，否则 Chrome 不会提前发起字体请求，只当普通资源处理 - 不能和
@font-face中的src值混用 base64 或 data URL；preload只支持网络地址
本地双击打开 HTML 时字体闪烁更严重？
是的，file:// 协议下字体加载行为和线上完全不同：没有 HTTP 缓存头、无服务端压缩、CORS 策略静默失效，甚至某些字体格式（如 woff2）在部分浏览器中根本不会触发 font-display 逻辑。
- 双击打开时，
font-display: block可能直接退化为无限制等待，导致白屏数秒 - 相对路径如
url(./fonts/xxx.woff2)在 file:// 下容易因当前工作目录不可靠而 404，浏览器反复重试，拉长阻塞时间 - 解决方案不是“修复”，而是绕过：用
python3 -m http.server或npx serve启一个本地 HTTP 服务，让字体加载回归标准流程
内联字体 Base64 真的能防闪烁吗？
能，但代价明显。Base64 内联把字体塞进 CSS，消除网络请求，实现“CSS 加载完即可用”，彻底避开 FOIT/FOFT。
- 只适用于小体积字体（建议 ≤ 10KB），否则 CSS 文件暴涨，首次渲染延迟反而更高
- woff2 的 Base64 编码后体积比原始大 ~33%，且无法被浏览器单独缓存，每次更新字体都要刷新整个 CSS 缓存
- 注意 MIME 类型必须写对：
url('data:font/woff2;base64,...')，错写成data:application/font-woff2会导致解析失败，降级为系统字体
最易被忽略的点：字体闪烁从来不是单一技术问题，而是 font-display + preload + 路径可靠性 + 服务协议（HTTP vs file://）共同作用的结果。改一个参数没用，得连着验。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
