用 font-display: swap 可避免字体加载闪动，它让浏览器先用备用字体渲染再替换；需配合 document.fonts.load() 和 document.fonts.ready 精准监听加载状态，并选用度量值相近的 fallback 字体，本地开发须启用 HTTP 服务而非 file:// 协议。
字体加载完成前页面闪动怎么压住
浏览器默认会等 @font-face 下载完才渲染文字，但实际中常出现“先用系统字体、再跳成自定义字体”的闪动（FOIT）；更糟的是某些浏览器（如旧版 Safari）直接空白几秒（FOUT）。这不是 bug，是字体加载策略的默认行为。
核心解法是用 font-display: swap，它告诉浏览器：字体没加载完，先用备用字体撑开布局，等加载成功再换过去——视觉不跳、布局不重排。
-
font-display: block：等太久就空白（默认值，慎用） -
font-display: swap：最常用，兼容性好（Chrome 60+、Firefox 60+、Safari 11.1+） -
font-display: fallback：只给极短等待期（100ms），适合标题类字体
示例：
@font-face {
font-family: "MyFont";
src: url("myfont.woff2") format("woff2");
font-display: swap;
}
怎么知道字体到底有没有加载成功
靠肉眼判断不准，尤其在弱网或缓存失效时。得用 JS 主动监听，而不是等 DOMContentLoaded 或 window.onload ——它们不反映字体状态。
立即学习“前端免费学习笔记（深入）”；
用 document.fonts.load() + document.fonts.ready 组合才是正解。前者触发加载，后者返回一个 Promise，真正代表“所有声明的字体都就绪了”。
- 必须传入完整字体描述，比如
"400 16px 'MyFont'，不能只写'MyFont' - 如果字体没声明过
@font-face，load()会静默失败，不报错也不 reject - 多个字体可链式调用：
document.fonts.load(...).then(() => document.fonts.load(...))
简单检测示例：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
document.fonts.load("400 16px 'MyFont'").then(() => {
document.body.classList.add("fonts-loaded");
});
CSS 中 fallback 字体选哪些才不翻车
fallback 不是随便写个 sans-serif 就完事。字体族名匹配失败，浏览器会退到下一个，最终落到系统默认，但这个过程可能破坏行高、字宽甚至换行位置。
关键原则：fallback 字体的 度量值（metrics）越接近主字体越好，否则即使加了 font-display: swap，也会出现文字“缩进突变”或“换行错位”。
- 优先用同类型已安装字体：比如主字体是无衬线体，fallback 用
-apple-system, BlinkMacSystemFont, "Segoe UI", Roboto - 避免混用衬线/无衬线，比如
"Times New Roman", "Helvetica"一起 fallback，字宽差异大 - Windows 和 macOS 的默认字体名不同，别漏掉
BlinkMacSystemFont或Segoe UI
推荐组合（Web 安全且度量稳定）：
font-family: "MyFont", -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif;
本地开发时字体总加载失败，路径和跨域怎么查
本地用 file:// 协议打开 HTML 时，@font-face 的 url() 路径基本都会 404——因为浏览器禁止 file 协议下的字体加载（安全限制），不是路径写错了。
必须起一个本地服务，哪怕最简的：npx serve 或 python3 -m http.server 8000。否则所有调试都是假象。
- 检查 Network 面板里字体请求的状态码：如果是
net::ERR_BLOCKED_BY_CLIENT，大概率是广告拦截插件干的 - 字体文件放在子目录时，
url()是相对 CSS 文件位置，不是 HTML 位置 - 部署后遇到 CORS 报错
Access to font at 'xxx' from origin 'yyy' has been blocked，说明字体服务器没配Access-Control-Allow-Origin: *
临时绕过 CORS（仅调试）：Chrome 启动时加参数 --disable-web-security --user-data-dir=/tmp，但别在日常浏览器用。
