HTML5中iframe字体缺失的根本原因是加载上下文隔离，iframe需独立声明@font-face且src路径须相对于自身URL；必须设置font-display:swap并确保MIME类型为font/woff2。
HTML5 嵌入页面（如 ）中字体缺失，根本原因不是“嵌入页不支持字体”，而是字体资源的加载上下文被隔离了—— 默认是独立文档，它不会自动继承父页面的 @font-face 声明，也不会自动访问父页面已加载的字体文件。
iframe 内部必须单独声明 @font-face
即使父页面已通过 @font-face 引入了 "HarmonyOS Sans"，iframe 里的 CSS 仍需重新定义，且 src 必须指向 iframe 自己能访问的路径（不能用 ../fonts/xxx.woff2 这种相对父页的路径）。
- 推荐把字体文件放在与 iframe HTML 同域、同目录（或明确可跨路径访问）的位置，例如：
./fonts/harmony.woff2 -
@font-face必须写在 iframe 页面自身的或外链 CSS 中，不能靠父页注入 - 注意字体文件 MIME 类型：服务器需返回
font/woff2（而非application/octet-stream），否则 Chrome/Firefox 会静默拒绝加载
父页无法直接向 iframe 注入字体 CSS（除非同源且主动操作）
跨域 iframe 完全无法读写其 DOM，同源 iframe 才能用 JS 注入样式。但不建议依赖 JS 动态注入，因为字体加载时机难控，易导致 FOIT/FOUT 加剧。
- 同源时可用：
iframe.contentDocument.head.appendChild(styleEl)，但 styleEl 中的@font-face仍需确保src路径对 iframe 上下文有效 - 若 iframe 是由第三方提供（如嵌入的 CMS 页面），你无法控制其 HTML/CSS，唯一可靠方式是让对方自己引入字体
- 不要尝试用
document.fonts.load()在父页预加载后“传递”给 iframe——字体实例不共享
使用 font-display: swap 是缓解 FOUT 的必要手段
即使字体声明正确，首次加载仍可能闪动。必须为每个 @font-face 显式设置 font-display: swap，否则浏览器默认行为是阻塞渲染（FOIT），尤其在慢网下用户看到空白文本时间过长。
立即学习“前端免费学习笔记（深入）”；
@font-face {
font-family: "HarmonyOS Sans";
src: url("./fonts/harmony.woff2") format("woff2");
font-display: swap; /* 关键 */
font-weight: 400;
}-
swap表示先用系统字体渲染，字体就绪后立即替换，视觉更平滑 - 避免用
auto（默认）或block，它们在字体未就绪时会让文字不可见 - 如果字体文件体积大（>100KB），考虑拆分字重/字宽为独立文件，按需加载
调试字体是否真正加载成功
仅看 DevTools 的 Network 面板不够——字体请求可能 200 成功，但因 CORS、MIME 或格式问题被浏览器丢弃。实际验证方法只有两个：
- 在 iframe 控制台执行：
document.fonts.check('400 16px "HarmonyOS Sans"')，返回true才算真正可用 - 手动修改 iframe 内某元素的
font-family为该字体，观察是否生效；若仍显示 fallback 字体（如sans-serif），说明加载失败或名称不匹配 - 检查字体文件是否支持目标平台：某些中文字体在 macOS 上需额外包含
unicode-range子集，否则 Safari 可能跳过加载
最常被忽略的是字体路径的上下文归属——你以为的 “相对路径” 其实是相对于 iframe 文档 URL，不是父页。多一层嵌套（比如 iframe src 是 /embed/v2/page.html），路径就要相应调整，这点连经验开发者也会反复踩坑。
