先说说核心结论：字体加载失败这件事，本身确实不会直接改变盒模型的计算规则——但别急着乐观。它带来的真正问题是，直接导致 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 是否覆盖了所有用到的字重和样式。
