font-size-adjust 这个 CSS 属性虽然听起来很有吸引力，但在实际项目中几乎无法用来解决跨浏览器字体排版问题。一句话概括：目前只有 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 也不会执行计算，所以后备字体出现时，字号突变、布局抖动的老问题依然存在。这才是最让人头疼的地方。
比 font-size-adjust 更可行的替代方案
既然这个属性靠不住，那我们就换用经过实测、可控性更强的方法：
- 使用无单位的
line-height: 1.5固定行高基准，避免因字体度量差异导致行高被重新计算。 - 在关键文本容器上加上
font-optical-sizing: none，禁用光学缩放干扰。特别是字体较小时，光学缩放会影响字形比例。 - 后备字体栈严格按照同类字体族编写，例如
font-family: 'Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif。这样可以避免混用衬线和无衬线字体，否则基线偏移会很麻烦。 - 如果必须控制基线，优先考虑 Chrome 125+ 已支持的
ascent-override和descent-override属性。这两个属性直接覆盖字体度量，不依赖浏览器的猜测。
其实真正容易被忽略的是：font-size-adjust 并不是什么“字体适配开关”，它只是 CSS 字体度量体系里一个长期未被广泛实现的补丁。在生产环境中，把它写进样式表，相当于默认放弃 Chrome 和 Safari 用户的排版一致性。因此，在实际开发中，我们还是应该依赖那些更靠谱的替代方案。
