移动端页面以rem为单位设置字体大小不生效解决方法

这个问题在前端H5页面开发可以说是一个老生常谈的问题了。由于以前所有遇到的问题以及解决方法都会以文档的形式记录在电脑里，而非github或者blog,所以现在才一点一滴的整理上来，就当是一个心路历程吧。

由于开发习惯，我现在使用HBuilder 这个前端IDE。调试页面会经常直接打开工具栏中的chrome,然后打开chrome devtool ,问题解决后，会直接把链接放到微信中，基于微信自带的浏览器浏览。这时候就比较蛋疼了，每一次更改一个css，然后在微信浏览，由于微信自带浏览器的机制问题，无法禁用缓存，每一次必须更改一下style的版本号，来看移动端真机情况下的样式。

由于UI调整，页面展示文字大小需要修改，修改以后，发现字体大小并没有改变，这就懵逼了。第一个想法就是浏览器缓存问题，然后杀数据，清缓存，改变版本，一通下来，小小期待的打开浏览器再次浏览，瞬间黑线！！！，然并卵！刷新几次，继续然并卵！既然与浏览器缓存没有关系，那就再想想其他方法。然后自然就是各种搜索，终于有了新的发现。原来这个特性被称做「Text Autosizer」，又称「Font Boosting」、「Font Inflation」，是 Webkit 给移动端浏览器提供的一个特性：当我们在手机上浏览网页时，很可能因为原始页面宽度较大，在手机屏幕上缩小后就看不清其中的文字了。而 Font Boosting 特性在这时会自动将其中的文字字体变大，保证在即不需要左右滑动屏幕，也不需要双击放大屏幕内容的前提下，也可以让人们方便的阅读页面中的文本，这应该就是webkit内核内部一个默认的机制问题。不过这个特性并不总是有必要的，还好在查到问题原因的同时，大家也讨论了对这个问题的一些处理方案：

手动指定 viewport width=320，这时 Font Boosting 不会被触发。（后边可以知道，这个说法不严谨，在其他设置均为默认值时，这一条才有效）
Font Boosting 仅在未限定尺寸的文本流中有效，给元素指定宽高，就可以避免 Font Boosting 被触发。
显然第 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 是如何计算的，这其中的逻辑又是什么？这有待考证。