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