本文是找了在网上搜了好久才找到非常棒的一篇文章，很好的解决了这个问题。
原文地址：https://github.com/amfe/article/issues/10
这个特性被称做「Text Autosizer」，又称「Font Boosting」、「Font Inflation」，是 Webkit 给移动端浏览器提供的一个特性：当我们在手机上浏览网页时，很可能因为原始页面宽度较大，在手机屏幕上缩小后就看不清其中的文字了。而 Font Boosting 特性在这时会自动将其中的文字字体变大，保证在即不需要左右滑动屏幕，也不需要双击放大屏幕内容的前提下，也可以让人们方便的阅读页面中的文本。
不过这个特性并不总是有必要的，还好在查到问题原因的同时，大家也讨论了对这个问题的一些处理方案：
- 手动指定
viewport width=320，这时 Font Boosting 不会被触发。（后边可以知道，这个说法不严谨，在其他设置均为默认值时，这一条才有效） - Font Boosting 仅在未限定尺寸的文本流中有效，给元素指定宽高，就可以避免 Font Boosting 被触发。
- 显然第 2 条方案是有缺陷的，文本内容不可能都指定宽高。不过还好，我们通过指定
max-height,（经 @Ovaldi 指正，只有min-height,min-width,max-widthmax-height有效） 也是可以的。比如body * { max-height: 999999px; }就可以无副作用的禁掉 Font Boosting 特性。当然，我觉得没必要使用通用选择器，用类似p { max-height: 999999px; }可能更好一些。
到这里，我们已经明白问题所在，并且也有解决方案了。但是有一个问题仍然困扰着我：当字体大于某一个值时（比如当不指定viewport width，手机屏幕width=320，字体大于等于82px时），这个 Font Boosting 就始终不会被触发。Chrome 是如何计算的，这其中的逻辑又是什么？
这一次问题解决起来就没有那么容易了，我先是各种搜索无果，然后自己人肉去试，慢慢找规律，但是发现变化不是线性的，看来这个公式还比较复杂。终于在今天被我发现了这篇文章：Chromium‘s Text Autosizer，彻底解释了我的疑问。
Font Boosting 具体的实现代码在 TextAutosizer.cpp 这个文件中可以看到，有兴趣的可以翻一下。
简单说来，Font Boosting 的计算规则伪代码如下：
multiplier = Math.max(1, deviceScaleAdjustment * textScalingSlider * systemFontScale * clusterWidth / screenWidth);
if (originFontSize < 16) {
computedFontSize = originFontSize * multiplier;
}
else if (16 <= originFontSize <= (32 * multiplier - 16)) {
computedFontSize = (originFontSize / 2) + (16 * multiplier - 8);
}
else if (originFontSize > (32 * multiplier - 16)) {
computedFontSize = originFontSize;
}
其中变量名解释如下，更具体的说明可以参考上边的两个链接。
originFontSize: 原始字体大小computedFontSize: 经过计算后的字体大小multiplier: 换算系数，值由以下几个值计算得到deviceScaleAdjustment: 当指定viewport width=device-width时此值为 1，否则值在 1.05 - 1.3 之间，有专门的计算规则textScalingSlider: 浏览器中手动指定的缩放比例，默认为 1systemFontScale: 系统字体大小，Android设备可以在「设备 - 显示 - 字体大小」处设置，默认为 1clusterWidth: 应用 Font Boosting 特性字体所在元素的宽度（如何确定这个元素请参考上边两个链接）screenWidth: 设备屏幕分辨率（DIPs, Density-Independent Pixels），如 iPhone 5 为 320
说了这么多，貌似只需要记住
指定的元素{ max-height: 999999px; }
用 max-height: 100% 可能会更好一些。