作者：京東物流 陳雨

作為一名開發(fā)者，bug 往往是我們最怕遇見的東西；而比遇到 bug 更可怕的事情，是定位不到 bug。作為一名前端開發(fā)者，與業(yè)務(wù)邏輯相關(guān)的 bug 還相對好定位、好解決一些；而一些與語法特性、平臺與設(shè)備差異相關(guān)的 bug 則更令人頭疼一些。這里記錄下我在工作中遇到過的稀奇古怪的前端問題，作為給自己的記錄和提醒。

用 vh 定義全屏顯示的問題

很多頁面因為設(shè)計效果的需要，要求正好鋪滿一整個顯示界面、也不允許上下滑動。做類似的需求時，往往直覺會使用這樣的代碼解決問題：

{
 height: 100vh;
}

這樣的代碼看似很優(yōu)雅，但是往往會有兼容性問題——不同瀏覽器定義的視口高度的定義不一致，導致 100vh 并不能真正覆蓋全視口高度；還有不少瀏覽器視口高度數(shù)值不變但實際視口大小可變，比如移動端 Chrome 瀏覽器的導航欄時不時隱藏但網(wǎng)頁獲取的視口高度不變，這都會導致最終顯示效果不符合預期。

如果要實現(xiàn)全屏幕覆蓋不可滑動，更為穩(wěn)妥和保險的方法是使用絕對定位：

{
 position: fixed;
 top: 0;
 bottom: 0;
 left: 0;
 right: 0;
}

帶 alpha 通道的 hex 顏色值失效的問題

在較新的 web 標準中，hex 格式的顏色代碼也可以表示透明度了，只需要在常見的六位 hex 顏色代碼后加兩位表示透明度的 hex 值，例如 #66ccff 表示一種藍色，而 #66ccff80 表示透明度 50% 的這種藍色（80 是 16 進制的 128，是 256 的一半，即 50% 透明度）。雖然直接這樣寫代碼的行為在前端開發(fā)中不普遍，但是設(shè)計師交付的視覺稿給出的參考值有不少是這種格式。如果直接把這樣的顏色代碼用于生產(chǎn)中，可能會出現(xiàn)以下兩種問題：

?如果你編寫的項目引入了 less 或者 sass，在進行打包構(gòu)建的操作時，部分預處理器無法正確識別帶 alpha 通道的 hex 顏色值，因此這部分代碼無法被正確轉(zhuǎn)譯，最終構(gòu)建出的生產(chǎn)環(huán)境代碼中這部分顏色可能丟失。

?部分移動端瀏覽器并未適配帶 alpha 通道的 hex 顏色值，因此即使是使用原生 css 完成的代碼，也有可能出現(xiàn)在部分手機或部分瀏覽器顏色不正常的問題。

生命周期函數(shù)不執(zhí)行的問題

在頁面剛打開或準備關(guān)閉時，我們往往需要進行一些諸如數(shù)據(jù)初始化、登入登出、數(shù)據(jù)上報等行為，而這些往往是借助 Vue 或 React 的生命周期函數(shù)完成的。不過，生命周期函數(shù)不執(zhí)行也是常被忽略的 bug，詳細來說，又可以分為兩類原因——

組件被 keep alive 導致未被卸載或重新加載

如果是 Vue 中使用 keep-alive 包裹的組件，或在 React 中使用類似的第三方庫 keep alive 的組件，只會在第一次加載時執(zhí)行生命周期初始化函數(shù)，且不會執(zhí)行生命周期卸載函數(shù)。這導致的不符合預期的行為很好解決，只需要使用 onActivated 代替 onMounted ，用 onDeactivated 代替 onUnmounted 即可。

頁面被直接關(guān)閉導致框架生命周期函數(shù)無法執(zhí)行

不管是 Vue 還是 React，生命周期函數(shù)的正確執(zhí)行都依賴于 Vue 或 React 實例的存在。而當用戶直接關(guān)閉瀏覽器頁面的時候，Vue 或 React 實例已經(jīng)被銷毀了，生命周期卸載函數(shù)當然就無法執(zhí)行了。處理這種情況也并不麻煩，只需要在生命周期初始化函數(shù)中添加對 window 卸載事件的監(jiān)聽，然后把想要進行的操作放到 window 卸載事件函數(shù)里就好了。

onMonted(() => {  
  window.addEventListener('beforeunload', () => {    
    // 需要執(zhí)行的代碼 
  });
});

文本中的 emoji 上下被裁剪

UGC 內(nèi)容中經(jīng)常出現(xiàn)文本和 emoji 混排的場景，而有時可能遇到 emoji 上下邊緣被裁剪的問題。這往往是由于開發(fā)頁面時為了限定文本高度和間距或其他排版方面的要求，將 line-height 和 font-size 設(shè)置為同樣的值，且 overflow 屬性被設(shè)置為 hidden 。如果出現(xiàn)類似情況，建議去除 line-height 的限制，而通過 margin 等方式控制行距，從而避免 emoji 被裁減。

輸入框被彈起的軟鍵盤覆蓋的問題

如果移動端頁面中有輸入框，那么很可能面臨輸入框被彈起的軟鍵盤覆蓋的問題。一般來講，對于需要彈起軟鍵盤的場景，較新的瀏覽器或者移動端 app 的 webview 會自動聚焦到輸入框中并滾動到相應位置，來保證輸入框的正常顯示；但是，對于如下兩種情況，彈起的軟鍵盤會將輸入框覆蓋，影響用戶輸入。

瀏覽器未能主動聚焦到輸入框

軟鍵盤彈起時，一般會從底部將頁面頂起、壓縮視口；視口高度變低了，原先處于顯示區(qū)域的輸入框可能就被擠到輸入框外了。如果用戶使用的瀏覽器版本較早或 app 內(nèi)置 webview 較為特殊，有可能在軟鍵盤彈出后瀏覽器未能主動聚焦到輸入框上。這時，開發(fā)者必須主動聚焦到輸入框并使輸入框滾動到視口內(nèi)。

const inputEle = document.querySelector('#target-input');inputEle.focus();inputEle.scrollIntoView();

軟鍵盤采用覆蓋在視口上層而非壓縮視口的方式彈出

如果瀏覽器或 webview 版本較為特殊，且輸入框處于頁面靠下的位置或者針對視口絕對定位于底部，那么可能會面臨更加復雜的情況。剛才已經(jīng)提到，正常情況下，軟鍵盤彈起的標準做法是從底部將頁面頂起、壓縮視口高度；但是某些情況下，軟鍵盤并不改變視口尺寸，而是直接蓋在視口上方。這就導致頁面邏輯上是展示完整的、輸入框也正常顯示在視口中；但軟鍵盤遮擋了半個頁面，也就真正意義上“覆蓋”在輸入框上。目前主流移動端瀏覽器較新的版本都不會出現(xiàn)這個問題，但是部分 app 內(nèi)置 webview 會設(shè)置為“軟鍵盤覆蓋在 webview 上方”；因此要解決這個問題，必須由客戶端更改 webview 的軟鍵盤設(shè)置。如果是很舊的瀏覽器版本或者無法推動客戶端開發(fā)解決問題，那就只能放棄治療了。