摘要：二分析排查一步驟一使用搜索引擎我是在無意中發(fā)現(xiàn)該問題的，當(dāng)時(shí)觀察到的現(xiàn)象是綁定在上的事件有時(shí)會(huì)被觸發(fā)，有時(shí)會(huì)失效。這說明并不存在偶爾失效的問題。也就是說，我需要找到確切的令響應(yīng)事件失效的原因。接下來的事很簡(jiǎn)單，繼續(xù)搜索事件在頁(yè)面滾動(dòng)后失效。

如果你關(guān)注我應(yīng)該知道，我最近對(duì)PC端頁(yè)面進(jìn)行移動(dòng)適配。在這個(gè)過程中，為了節(jié)省用戶300ms的時(shí)間，同時(shí)給予用戶更及時(shí)的點(diǎn)擊反饋（這意味著更好的用戶體驗(yàn)），我在嘗試使用移動(dòng)端獨(dú)有的 touchstart 事件替代傳統(tǒng)的 click 事件，這過程中我遇到了一些小問題，并成功解決了，你可以通過這篇文章查看具體的情況。

所謂禍不單行，在即將發(fā)布上線的時(shí)候，我又突然發(fā)現(xiàn)使用 touchstart 事件后，移動(dòng)設(shè)備上出現(xiàn)了另一個(gè)比較詭異的現(xiàn)象：當(dāng)用戶滾動(dòng)頁(yè)面后，原本綁定在fixed定位的navbar元素上的 touchstart 事件會(huì)時(shí)常失效。你可以通過掃描下方二維碼，并使用你的Safari瀏覽器或Chrome瀏覽器（注意：不是瀏覽器自帶的模擬器）親自感受這一奇怪的現(xiàn)象。

當(dāng)然，最終我成功解決了這個(gè)問題，并且有意思的是，這個(gè)問題似乎并不出自我的代碼，而被我歸咎于是瀏覽器的Bug。但是對(duì)于這個(gè)Bug出現(xiàn)的原理，我也只有一個(gè)大概的推測(cè)，如果你清楚的知道產(chǎn)生這一現(xiàn)象的原因，也歡迎你和我分享。

在本篇文章中，我不但會(huì)記錄我的解決方案，并且會(huì)記錄我在遇到這個(gè)問題后的debug的過程與分析思路。不過如果你正被這個(gè)問題搞得焦頭爛額，只想快點(diǎn)擺脫這個(gè)問題，你可以直接翻閱到文章底部“解決方案”部分，參考我的解決方案（我真是貼心，對(duì)吧？ ?）。

移動(dòng)設(shè)備：iPhone 6

操作系統(tǒng)：iOS 11.2.5

測(cè)試瀏覽器：Safari，Chrome

點(diǎn)擊此處查看示例代碼

當(dāng)在移動(dòng)設(shè)備上使用測(cè)試瀏覽器打開網(wǎng)頁(yè)并滾動(dòng)屏幕后，會(huì)發(fā)現(xiàn)再次點(diǎn)擊navbar，navbar元素綁定的 touchstart 事件并沒有被觸發(fā)（或偶爾不被觸發(fā)）。

我是在無意中發(fā)現(xiàn)該問題的，當(dāng)時(shí)觀察到的現(xiàn)象是綁定在navbar上的 touchstart 事件有時(shí)會(huì)被觸發(fā)，有時(shí)會(huì)失效。于是我使用Google搜索了“touchstart 事件偶爾失效”的關(guān)鍵字，很遺憾，并沒有什么靠譜的答案。這說明“并不存在touchstart偶爾失效的問題”。也就是說，我需要找到確切的令 touchstart 響應(yīng)事件失效的原因。

接下來，我不斷的在移動(dòng)設(shè)備上嘗試各種操作（雙擊，滾動(dòng)屏幕，放大等），并留心移動(dòng)設(shè)備的響應(yīng)，最終將 touchstart 綁定事件失效的原因確定為在“頁(yè)面滾動(dòng)之后”。接下來的事很簡(jiǎn)單，繼續(xù)Google搜索“touchstart 事件在頁(yè)面滾動(dòng)后失效”。觀察首屏搜索結(jié)果，并點(diǎn)擊進(jìn)去查看，遺憾的是，并沒有什么合適的信息：

接著我抱著試試看的態(tài)度切換百度搜索同樣的關(guān)鍵詞，還不錯(cuò)，已經(jīng)有了一個(gè)相似度很高的搜索結(jié)果，但是閱讀后發(fā)現(xiàn)依然不是我想要的：

是時(shí)候上最終的大殺器了，使用英文關(guān)鍵字搜索！以下是我使用了“touch event doesn"t respond after page scroll”關(guān)鍵字的Google搜索結(jié)果：

老樣子，還是沒有令人滿意的結(jié)果。至此我獲得了兩點(diǎn)信息：

可能是我的代碼寫的有問題：因?yàn)楹苄】赡艹霈F(xiàn)奇怪的現(xiàn)象從來沒有人遇到過；

我應(yīng)該從 touch 事件的相關(guān)概念上找原因；

至此，debug的第一階段結(jié)束，我的徒勞無功表明了這個(gè)問題并不簡(jiǎn)單，我需要認(rèn)真對(duì)待，接下來我采用了以下兩種方法：

抽離核心代碼，通過隔離外界不確定因素，排除外因；

查閱MDN上touch事件的文檔，查找可能引發(fā)此類問題的內(nèi)因；

思路很清晰對(duì)吧，但是我并沒有在相關(guān)文檔中找到可能引發(fā)此問題的任何靈感。不過好在我通過第一步已經(jīng)讓問題變得非常清晰了，不要灰心，繼續(xù)思考。

基本上到了這個(gè)階段，debug的過程就進(jìn)入到經(jīng)驗(yàn)和直覺領(lǐng)域了，要成功解決這個(gè)問題，你有時(shí)還需要一點(diǎn)點(diǎn)運(yùn)氣，我在這個(gè)過程中嘗試了以下方案：

“無腦試對(duì)”：我將在搜索引擎中看到的一些問題的解決方法，逐個(gè)試驗(yàn)，希望有個(gè)會(huì)管用，我可以獲得更多信息去定位問題出現(xiàn)的原因。這些嘗試有：為事件的回調(diào)函數(shù)添加 e.preventDefault() 方法，替換 touchstart 事件為 touchend 事件或者直接是 click 事件。

很尷尬，這些嘗試都沒有起到作用，問題依然存在，不過沒有關(guān)系，我本來也沒有對(duì)這個(gè)簡(jiǎn)短的嘗試抱太大的期望，不過這其實(shí)也說明這個(gè)奇怪的現(xiàn)象和touch具體的事件類型無關(guān)，和touch事件誤觸發(fā)其余事件無關(guān)。

目前為止，我已經(jīng)知道了 touch 事件我使用的方式是正確的，并且沒有其余的因素可以干擾點(diǎn)擊事件的觸發(fā)，自然而然的，我開始好奇，瀏覽器到底有沒有檢測(cè)到我手指的“點(diǎn)擊”。這可以通過以下代碼得到答案：

window.addEventListener("touchstart", e => {
    console.log(e.target)
})

奇妙的事情發(fā)生了，我的navbar居然不再出現(xiàn)頁(yè)面滾動(dòng)后touch事件失效的問題！但是當(dāng)我按照相同的思路，將代碼替換為下面的代碼想要看看返回值時(shí)：

var navbar = document.querySelector(".navbar")

navbar.addEventListener("touchstart", e => {
    console.log(e.target)
})

問題又出現(xiàn)了，并且當(dāng)頁(yè)面滾動(dòng)后，每當(dāng)我再次點(diǎn)擊navbar，控制臺(tái)沒有任何輸出，這意味著瀏覽器認(rèn)為我并沒有點(diǎn)擊navbar！

這不科學(xué)，但是我已然看到勝利的曙光。當(dāng)我我將原先綁定在navbar上的 touchstart 事件通過事件的冒泡機(jī)制綁定在 window 對(duì)象，通過判斷 e.target 屬性進(jìn)行事件回調(diào)時(shí) -- 問題解決了，頁(yè)面正常了，整個(gè)世界都清凈了...

代碼如下：

var navbar = document.querySelector(".navbar")

window.addEventListener("touchstart", e => {
    if (e.target === navbar) {
        // callback
    }
})

掃描二維碼查看正確的效果：

到此為止問題被成功解決了嗎？并沒有。

雖然世界清凈了的那一刻令人神清氣爽，但是這只是需求被實(shí)現(xiàn)了，問題并沒有被解決，我指的是我心里的那個(gè)問題：“為什么這樣就行，而原來那樣就不行？”。這個(gè)問題至關(guān)重要，也希望你們不要忽略。

你同意嗎？那讓我們繼續(xù)。

讓我們?cè)倩剡^頭分析一下我們的代碼，很明顯它已經(jīng)非常精簡(jiǎn)了，唯一可能出問題的地方在于我們給navbar的 fixed 定位。我們?cè)傧胂胛覀兪窃趺础罢`打誤撞”解決這個(gè)問題的，navbar檢測(cè)不到我們的點(diǎn)擊，但是window可以，將這兩個(gè)線索放在一起思考，我得出了一個(gè)很值得懷疑的對(duì)象：層級(jí)。

我試著取消了navbar的 position: fixed; 聲明，果然，一切又都正常了?？磥磉@一奇異現(xiàn)象的始作俑者就是這條聲明。而我能想到與之相關(guān)的因素就是層級(jí)，我是指DOM對(duì)象的層級(jí)。

最終我是這樣解釋這個(gè)奇怪現(xiàn)象產(chǎn)生的原因：

在頁(yè)面初始化時(shí)，瀏覽器的DOM樹被正確的渲染，也就是說DOM元素間的關(guān)系正確，因此 navbar 元素可以準(zhǔn)確的捕捉我們的 touchstart 事件，但是當(dāng)頁(yè)面滾動(dòng)后，瀏覽器丟失了 navbar 元素的層級(jí)關(guān)系， touchstart 事件無法通過冒泡被 navbar 元素捕捉，因此我們綁定的事件沒有響應(yīng)。而當(dāng)我們讓整個(gè)window對(duì)象監(jiān)測(cè) touchstart 事件后，瀏覽器可以重新正確的計(jì)算DOM對(duì)象間的關(guān)系，navbar 層可以捕捉到冒泡的事件，因此一切就都正常了。

這個(gè)解釋有說服你嗎？其實(shí)我心里也沒個(gè)底，畢竟這只是我基于現(xiàn)象的一種推測(cè)。但無論如何，這種奇怪現(xiàn)象的發(fā)生，應(yīng)該被歸咎于瀏覽器，而不是我的代碼（哈，松了一口氣）。

到這里，這個(gè)問題就結(jié)束了嗎？并沒有。如果只是憑一個(gè)現(xiàn)象，一個(gè)推測(cè)就甩鍋瀏覽器，會(huì)不會(huì)讓人有一種欽定的感覺，讓某些人不服呢？會(huì)的，我自己心就比較虛，不過沒關(guān)系，只要掌握了以下的關(guān)鍵訣竅，甩鍋瀏覽器還不是分分鐘的事。

該訣竅就是 -- 你自己去多測(cè)幾個(gè)瀏覽器啊，朋友?。?/p>

我們根據(jù)引擎區(qū)分不同瀏覽器，

使用Webkit引擎的瀏覽器：Chrome，Safari

使用Gecko引擎的瀏覽器：Firefox

使用Presto引擎的瀏覽器：Opera

于是我下載了Firefox瀏覽器重新測(cè)試了原代碼下頁(yè)面效果，果然沒有問題！

呵呵，不是我代碼的問題。都是使用Webkit引擎的瀏覽器不好 ：）。

你以為本篇文章就這么結(jié)束了？并沒有（失望吧），實(shí)際上寫到這里，你應(yīng)該也有所感覺，雖然這次debug成功解決了問題，但整個(gè)過程并不流暢高效，并且在其中走了些許彎路。結(jié)合本次debug的經(jīng)驗(yàn)，我總結(jié)了以下幾個(gè)在下次debug過程中需要注意的方面：

依次使用Google，Google（英文關(guān)鍵字），百度搜索引擎搜索問題關(guān)鍵字；

對(duì)沒有搜索到結(jié)果的問題保持警惕（檢查自己的代碼）；

編寫Demo，隔離核心代碼，簡(jiǎn)化分析背景；

確保掌握相關(guān)技術(shù)知識(shí)點(diǎn)；

首先使用各瀏覽器測(cè)試（這樣便可以盡早排除是否是瀏覽器Bug）；

盡早使用 debugger 關(guān)鍵字而不是 console.log 方法進(jìn)行調(diào)試；（沒錯(cuò)，debugger 關(guān)鍵字讓調(diào)試更高效）；

仔細(xì)觀察問題，大膽假設(shè)，小心求證；

不要放棄，在解決需求后，要解決問題；

如果有時(shí)間精力的話，將發(fā)現(xiàn)的問題和debug過程中學(xué)到的知識(shí)總結(jié)一篇博客吧 ：）；

以上，是我在實(shí)際開發(fā)過程中發(fā)現(xiàn)問題，分析問題并解決問題的過程和思路，希望對(duì)你們有幫助。