做一个手机端页面时，遇到了一个奇怪的问题：字体的显示大小，与在CSS中指定的大小不一致

最近在做一个手机端页面时，遇到了一个奇怪的问题：字体的显示大小，与在CSS中指定的大小不一致。

就如上图所示，你可以发现，原本指定的字体大小是24px，但是最终计算出来的却是32px，看到这诡异的结果，我心中暗骂一句：这什么鬼！

随后开始对问题各种排查：某个标签引起的？某个CSS引起的？又或者是某句JS代码引起的。通过一坨坨的删代码，发现貌似都不是。我不禁又骂，到底 什么鬼！不过中间还是发现了一些端倪：当页面中的标签数量或者文本数量大于某一个值，或者当CSS定义的字体大小落在某个区间时，这个问题才会被触发。而 且字体变大后的值也随着原始定义的字体大小而改变。

然后自然就是各种搜索，终于有了新的发现。原来这个特性被称做「Text Autosizer」，又称「Font Boosting」、「Font Inflation」，是 Webkit 给移动端浏览器提供的一个特性：当我们在手机上浏览网页时，很可能因为原始页面宽度较大，在手机屏幕上缩小后就看不清其中的文字了。而 Font Boosting 特性在这时会自动将其中的文字字体变大，保证在即不需要左右滑动屏幕，也不需要双击放大屏幕内容的前提下，也可以让人们方便的阅读页面中的文本。

不过这个特性并不总是有必要的，还好在查到问题原因的同时，大家也讨论了对这个问题的一些处理方案：

1. 手动指定 viewport width=320，这时 Font Boosting 不会被触发。（后边可以知道，这个说法不严谨，在其他设置均为默认值时，这一条才有效）
2. Font Boosting 仅在未限定尺寸的文本流中有效，给元素指定宽高，就可以避免 Font Boosting 被触发。
3. 显然第 2 条方案是有缺陷的，文本内容不可能都指定宽高。不过还好，我们通过指定 max-height ,min-height, min-width, max-width（经 @Ovaldi 指 正，只有 max-height 有效） 也是可以的。比如body * { max-height: 999999px; } 就可以无副作用的禁掉 Font Boosting 特性。当然，我觉得没必要使用通用选择器，用类似 p { max-height: 999999px; } 可能更好一些。

到这里，我们已经明白问题所在，并且也有解决方案了。但是有一个问题仍然困扰着我：当字体大于某一个值时（比如当不指定viewport width，手机屏幕width=320，字体大于等于82px时），这个 Font Boosting 就始终不会被触发。Chrome 是如何计算的，这其中的逻辑又是什么？