這個問題在前端h5頁面開發可以說是乙個老生常談的問題了。由於以前所有遇到的問題以及解決方法都會以文件的形式記錄在電腦裡，而非github或者blog,所以現在才一點一滴的整理上來，就當是乙個心路歷程吧。
由於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 * 就可以無***的禁掉 font boosting 特性。當然，我覺得沒必要使用通用選擇器，用類似 p 可能更好一些。
到這裡，我們已經明白問題所在，並且也有解決方案了。但是有乙個問題仍然困擾著我：當字型大於某乙個值時（比如當不指定viewport width，手機螢幕width=320，字型大於等於82px時），這個 font boosting 就始終不會被觸發。chrome 是如何計算的，這其中的邏輯又是什麼？這有待考證。
移動端 單位 rem
rem是指相對於根元素的字型大小的單位 相對單位 rem和em的區別，em相對于父元素的字型大小的單位。rem相對於根元素html字型大小計算，px是乙個絕對的單位。所以rem可以實現強大的螢幕適配布局 例如 html btn 那麼.btn的寬度為120px 高度為60px 所以在做移動端適配的時候...
移動端適配rem單位
1.rem單位 描述 rem是css中的乙個尺寸單位，和px，em等單位一樣，都是用來設定大小的。rem代表的含義為 是html的字型大小的多少倍 語法 document.documentelement.style.fontsize document.documentelement.clientwi...
JS PC端設定rem 移動端設定rem
window.onresize function 頁面剛重新整理時呼叫 init function init const basesize 32function setrem 初始化 setrem window.onresize function 這裡是乙個pc和h5的 rem樣式 寫在了乙個htm...