起
其實這個問題來源于吸頂?shù)膶崿F(xiàn)。CSS中定位使用sticky屬性，可以直接實現(xiàn)吸頂效果。參考sticky headings。但是好事多磨，較低版本的Android并不支持。而fixed屬性在iOS上又有一些問題，所以面對這個需求，采用了判斷env的方法，iOS用sticky，Android用fixed，基本可以完美實現(xiàn)。盡管寫起來并不太開心，因為對于fixed還要監(jiān)聽滾動事件。
其實也還好，人要知足，這需求只要兼容iOS和Android，不需要考慮IE的。但是問題來了，開發(fā)的時候還是要用Chrome的，在Chrome上會發(fā)現(xiàn)吸頂后上面有1px的縫隙。
承
但是吧，我在iPhone上測試沒有任何毛病，所以就沒太關(guān)心這個bug，反正這個網(wǎng)頁是放在app里的，不支持瀏覽器打開。直到，我的leader用他的Android手機打開這個頁面，復現(xiàn)了！好端端的怎么就復現(xiàn)了呢？講道理我是判斷了env，Android會自動fixed，不會有這種問題。他說他的手機支持Chromium的內(nèi)核，版本還挺新。所以不得不去解決。
轉(zhuǎn)
不過呢，這是一個非常小的細節(jié)，并且我還有別的事情要做，就先擱置了。那個「別的事情」就是要優(yōu)化一下圖片加載閃動的問題，提前給圖片占位。由于后端給的圖片尺寸確定，所以我寫死了高度。居然，sticky的1px問題也沒了。我反復調(diào)試了一下，確實是因為我給它上面的圖片寫了高度。
盡管我已經(jīng)解決了問題，但是！
感覺像是Chrome沒有計算好文檔流中前序元素的高度，所以我打開CodePen，也就是文章開頭的鏈接。確實如此，我把前面的h1標簽刪掉就好了，或者改成一個普通的div也沒問題。由此可以認為，這是Chrome自己的處理出了瑕疵，起碼不是我的鍋了。我測試了Safari on macOS沒毛病，Safari on iOS沒毛病，wkwebview沒毛病，只有Chrome和Chromium for WebView有這個問題。
然后我在爆棧網(wǎng)上看到了類似的問題，沒什么回答，就把自己的踩坑過程寫了上去Stack Overflow
順便去Chromium上搜了一下，14小時前有人問過一樣的問題…… Chromium，于是我在評論里也吐槽了一把。
合
解決方案就是在Chromium內(nèi)核里盡量不用這個屬性，以避免遇到這種詭異bug。如果必須要用，或者兼容使用時為了保險，可以嘗試在sticky元素的上方元素中調(diào)試，比如使用div，寫死高度等隨緣調(diào)試法。
