這個問題在前端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 是如何計算的，這其中的邏輯又是什么？這有待考證。