作者：京東物流 陳雨

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

用 vh 定義全屏顯示的問題

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

{
 height: 100vh;
}

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

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

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

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

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

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

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

生命周期函數不執行的問題

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

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

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

頁面被直接關閉導致框架生命周期函數無法執行

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

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

文本中的 emoji 上下被裁剪

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

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

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

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

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

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

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

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