全局字体加载失败对盒模型尺寸的影响分析

先说说核心结论：字体加载失败这件事，本身确实不会直接改变盒模型的计算规则——但别急着乐观。它带来的真正问题是，直接导致 content 区域的宽度和高度发生“突变”，紧接着 margin、padding、border 的视觉表现就会失调，重排甚至父容器高度塌陷都可能接踵而至。说白了，这不是你写的 box-sizing 出了岔子，而是文字撑开空间的“基准”发生了变化。

你可能会发现文字宽度变了、布局跳跃了、父容器塌陷了——第一反应往往是怀疑 box-sizing 写错了。但别着急，问题通常出现在更早的环节。

font-display: swap 未启用，布局跳动将难以避免

如果没有设置 font-display: swap，浏览器默认采用 font-display: auto（实际上相当于 block），它会阻塞文本渲染最多 3 秒。在此期间，如果字体文件返回 404 或超时，页面要么一片空白，要么突然出现系统字体的“闪入”。此时，无论是 fillText() 还是 DOM 中的文本流，宽度都已按照系统字体重新计算，整个 layout 也会随之重排。

• 在 Canvas 中使用 fillText() 时，如果指定的 font-family 名称尚未激活，它会悄然降级为 sans-serif，并且不会触发重绘——这种表现相当隐蔽。
• 举个例子：一个盒子设置 width: 100px 并附加 padding: 10px，内容文字宽度从 80px（自定义字体）突然变成 110px（Arial），那么实际占用的宽度就会从 100px 扩大到 130px。如果父容器没有设置 min-height，高度立刻塌陷。
• 如何排查？打开开发者工具，查看 Computed → font-family，如果显示的是 "Times New Roman", serif 而非你声明的字体，基本就能确认是加载失败或尚未激活。

@font-face 声明缺失 font-weight 或 font-style，盒模型尺寸同样会紊乱

即便字体文件成功加载，如果 @font-face 声明中缺少 font-weight: 600，而 CSS 中又使用了 font-weight: 600，浏览器将无法匹配到对应的字重，自动回退到系统字体——文本宽度随之改变，盒模型看起来“尺寸不对”，实质是 content 宽度在暗自修改。

• 关键要点：每个实际使用的字重和样式都必须单独编写一个 @font-face 块。不要指望只声明一个 font-weight: 400 就能覆盖全部。
• font-style: italic 同理：如果使用了 em 或斜体标签却没有声明对应的 @font-face，就会发生回退，而且斜体通常更窄，宽度变化更为隐蔽。
• 检查方法：在 Elements 面板中选中文字元素 → Styles → 展开 font 简写属性，查看右侧是否有标红或显示“inherited”，再点开 font-family 确认最终生效的值。

document.fonts.load() 尚未完成就绘制 canvas，尺寸错位几乎必然发生

在 HTML5 小游戏或动态文本渲染场景中，canvas 2D 的 fillText() 完全不会感知字体加载状态。即使 @font-face 已声明、font-display: swap 已启用，只要 document.fonts.load() 的 Promise 尚未 resolve，measureText() 返回的宽度就是错误的。随后基于这个宽度进行的定位、换行、裁剪，都会出现偏移。

• 正确做法：先调用 await document.fonts.load("600 16px 'MyFont'")（注意字符串格式必须与 ctx.font 一致），然后再执行 ctx.fillText()。
• 不要依赖 window.onload 或 DOMContentLoaded——它们并不能保证字体已就绪。也不要使用 setTimeout 硬等，网络波动下这种做法不可靠。
• 如果需要等待多个字体，建议使用 Promise.all([font1, font2])，避免串行等待拖长首屏渲染时间。

DOCTYPE 错误或怪异模式会加剧问题

一旦 document.compatMode === "BackCompat"，浏览器就进入了怪异模式。此时不仅 box-sizing 的行为会退化，连 getBoundingClientRect() 返回的宽高都可能不准确——字体宽度变化叠加盒模型逻辑混乱，debug 成本直接翻倍。

• 立即在控制台执行 document.compatMode，如果结果不是 "CSS1Compat"，就必须先修复 DOCTYPE：必须是 ，全小写、无空格、无 BOM，且不能放在任何注释之前。
• 在怪异模式下，即使你写了 box-sizing: border-box，某些旧式计算仍会按照 IE5.5 的规则执行，比如 width 是否包含 border 都可能变得不稳定。
• 修复后刷新页面，再观察字体加载失败时的 layout 表现——至少能排除“究竟是盒模型本身错了，还是内容撑开错了”的干扰。

最容易被忽略的一点是：字体加载失败引发的尺寸异常，90% 不是 CSS 写错了，而是你根本没有等到字体就绪就去测量或绘制。别急着调整 box-sizing 或重写布局，先确认 document.fonts.load() 是否真正完成、font-display: swap 是否生效、@font-face 是否覆盖了所有用到的字重和样式。