CSS font-size-adjust跨浏览器字体排版优化指南

font-size-adjust 听起来很美，但在实际项目里，它几乎没法帮你解决跨浏览器字体排版的问题。一句话总结就是：这东西吧，目前只有 Firefox 能稳定支持，Chrome 从 127 版开始已经撤掉了实验开关，Safari 压根不理它，Edge 跟着 Chrome 走。可惜了，它的设计初衷其实是好的——想通过缩放 x-height 来让后备字体和首选字体看起来协调一致。但问题出在哪呢？

需要明确指出：font-size-adjust 几乎无法在实际项目中用于跨浏览器字体排版优化——它只在 Firefox 中稳定生效，Chrome 和 Safari 均不支持（截至 2026 年 6 月）。 换言之，无论开发者编写多少条声明，Chrome 和 Safari 用户看到的页面效果依然不会改变。

font-size-adjust 的真实支持范围

该属性的浏览器兼容性可以用“惨不忍睹”来形容：

• Firefox 从 3.0 开始就完整支持了，font-size-adjust: 0.58 这类写法能正常触发 x-height 的缩放计算。
• Chrome 曾在 43 到 126 版本之间作为实验特性存在，用户必须手动前往 chrome://flags/#enable-experimental-web-platform-features 开启开关。但自 127 版本开始，这个开关已被直接移除。
• Safari 则完全忽略这个属性。声明写入后，浏览器虽会解析，但不会产生任何实际效果。
• Edge（基于 Chromium）与 Chrome 策略同步，当前版本（126 以上）也已不再支持。

它想解决什么，又为什么失效

font-size-adjust 的设计初衷是：当首选字体（例如 'Inter'）无法加载时，让后备字体（例如 system-ui）按相同的 x-height 进行渲染。其计算公式为 c = (a / a') * s。听起来具备一定智能，但实际执行中存在诸多问题。

首先，它依赖浏览器获知后备字体的 aspect value（即 x-height 与 font-size 的比值）。然而系统字体的 aspect 值并未标准化，macOS 的 San Francisco 与 Windows 的 Segoe UI 差异显著。这如同让身高 1.8 米的人与 1.6 米的人穿同一件衣服，自然难以贴合。

其次，中文字体几乎不参与这一机制。主流中文字体（如 Noto Sans CJK、PingFang SC）缺乏公开、稳定的 aspect 值，且浏览器通常不会主动测量这些字体的该数值。因此，在中文应用场景下，font-size-adjust 基本属于摆设。

最后，即便开发者获取了 aspect 值，由于 Safari 和 Chrome 不会执行相关计算，当字体 fallback 时依然会出现字号突变、布局抖动等问题。这才是真正的核心痛点。

比 font-size-adjust 更可行的替代方案

既然该属性并不可靠，可以采用以下实测可控的方法进行替代：

• 使用 line-height: 1.5（无单位）固定行高基准，避免因字体 metrics 差异导致行高被重新计算。
• 对关键文本容器添加 font-optical-sizing: none，禁用光学缩放干扰。该属性在小字号时尤其会影响字形比例。
• 后备字体栈应严格按照同类字体族书写，例如 font-family: 'Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif。这可以避免混用衬线和无衬线字体，防止 baseline 偏移带来的排版问题。
• 如果必须控制基线，优先考虑 Chrome 125+ 已支持的 ascent-override 和 descent-override。这两个属性直接覆盖字体度量，不依赖浏览器自行估算。

容易被忽略的一点是：font-size-adjust 并不等同于“字体适配开关”，它仅仅是 CSS 字体度量体系中一个始终未被广泛实现的补丁。在生产环境中将其写入样式表，相当于默认放弃 Chrome 和 Safari 用户的排版一致性。因此，实际开发中仍需依赖更为可靠的替代方案。