1. 事件流點(diǎn)擊一下按鈕背后發(fā)生了什么1.1 事件流的三階段模型瀏覽器在接收到一次交互比如點(diǎn)擊之后并不是直接把事件交給目標(biāo)元素處理就完了而是會(huì)經(jīng)過(guò)一個(gè)完整的傳播鏈路這就是事件流。我在解釋這個(gè)概念時(shí)經(jīng)常用快遞送貨來(lái)類(lèi)比一個(gè)快遞包裹從倉(cāng)庫(kù)發(fā)出沿著主干線運(yùn)到收件人所在的小區(qū)再送到收件人手上之后簽收信息還要沿路返回驛站和倉(cāng)庫(kù)。瀏覽器里的一個(gè)事件就是這樣先在 Window 一路往下走、觸達(dá)真正的目標(biāo)元素、再一路往上返回的。這個(gè)鏈路被明確劃分為三個(gè)階段捕獲階段capture phase、目標(biāo)階段target phase和冒泡階段bubble phase。捕獲階段從 Window 開(kāi)始依次經(jīng)過(guò) document、html、body 以及各級(jí)父元素一路向下直到目標(biāo)元素的父節(jié)點(diǎn)目標(biāo)階段是事件真正到達(dá)目標(biāo)元素本身之后進(jìn)入冒泡階段事件又從目標(biāo)元素逐層向上傳播回到 Window。三個(gè)階段加在一起構(gòu)成了一個(gè)完整的傳播閉環(huán)。這里要特意強(qiáng)調(diào)一個(gè)容易讓新人懵的點(diǎn)在目標(biāo)階段判斷事件做捕獲還是冒泡看的是監(jiān)聽(tīng)器綁定的時(shí)機(jī)而不是元素所在的位置。具體來(lái)說(shuō)如果你的監(jiān)聽(tīng)器設(shè)置了捕獲模式并且在目標(biāo)元素上觸發(fā)了那這個(gè)監(jiān)聽(tīng)器在目標(biāo)階段的執(zhí)行順序會(huì)優(yōu)先于普通冒泡模式下的監(jiān)聽(tīng)器。這里不要和目標(biāo)階段既不是捕獲也不是冒泡的說(shuō)法搞混階段屬于事件傳播的位置概念而監(jiān)聽(tīng)模式屬于這個(gè)監(jiān)聽(tīng)器想在哪一步介入的問(wèn)題。理解了這個(gè)區(qū)別后面寫(xiě)復(fù)雜交互時(shí)就不會(huì)在順序上翻車(chē)。1.2 捕獲與冒泡的歷史由來(lái)為什么瀏覽器要把事件設(shè)計(jì)成這么繞的傳播方式這其實(shí)是一段真實(shí)的歷史遺留。早期網(wǎng)景公司和 IE 在事件傳播模型上各執(zhí)一詞網(wǎng)景覺(jué)得事件應(yīng)該從外層向內(nèi)層傳播也就是捕獲IE 認(rèn)為事件應(yīng)該從內(nèi)向外冒泡。標(biāo)準(zhǔn)之爭(zhēng)導(dǎo)致早期的前端代碼里充斥著各種兼容性判斷同一套交互邏輯在兩邊瀏覽器里表現(xiàn)還不一樣。最后 W3C 在 DOM 標(biāo)準(zhǔn)里做了一個(gè)非常務(wù)實(shí)的選擇兩個(gè)模型你都可以用事件會(huì)先捕獲后冒泡在這個(gè)完整鏈路里開(kāi)發(fā)者可以自由選擇事件在哪一端被處理。這也是現(xiàn)在所有現(xiàn)代瀏覽器統(tǒng)一的行為。我在日常開(kāi)發(fā)中默認(rèn)使用冒泡模式居多因?yàn)閷?duì)一個(gè)具體的交互場(chǎng)景來(lái)說(shuō)冒泡階段更符合事件從目標(biāo)元素開(kāi)始往外擴(kuò)散的直覺(jué)而且事件委托這種核心技巧正是建立在冒泡基礎(chǔ)上的。但也別把捕獲當(dāng)成冷門(mén)功能。有些場(chǎng)景只有捕獲模式才靠譜比如讓一個(gè)外層容器先于內(nèi)層元素獲得事件處理機(jī)會(huì)、攔截某些不該發(fā)生的交互或者在事件到達(dá)目標(biāo)之前統(tǒng)一做預(yù)處理。了解和會(huì)用捕獲在處理復(fù)雜表單校驗(yàn)、鍵盤(pán)快捷鍵攔截這類(lèi)需求時(shí)會(huì)有很大幫助。1.3 事件流的實(shí)戰(zhàn)觀察紙上談兵沒(méi)意義建議你在瀏覽器控制臺(tái)里跑一段代碼親自驗(yàn)證。給每個(gè)節(jié)點(diǎn)都同時(shí)綁定捕獲和冒泡兩個(gè)監(jiān)聽(tīng)器然后點(diǎn)擊最內(nèi)層的元素打印結(jié)果。你會(huì)發(fā)現(xiàn)順序是先外層捕獲、再內(nèi)層捕獲、再到目標(biāo)元素、之后依次外層的冒泡。這個(gè)規(guī)律非常穩(wěn)定熟悉之后你讀別人代碼里各種 handle 回調(diào)的觸發(fā)順序時(shí)就有了坐標(biāo)系。我還比較推薦觀察event.eventPhase這個(gè)字段它的值為 1、2、3 時(shí)分別代表事件正處于捕獲階段、目標(biāo)階段、冒泡階段。調(diào)試復(fù)雜嵌套組件時(shí)我會(huì)通過(guò)打印event.eventPhase來(lái)確認(rèn)當(dāng)前事件到底在哪個(gè)階段從而判斷是不是綁定階段選錯(cuò)了。這個(gè)字段平時(shí)用得不多但關(guān)鍵時(shí)刻能省不少排查時(shí)間。另外要提醒一點(diǎn)focus、blur這類(lèi)事件本身不支持冒泡但它們?cè)诓东@階段可以被外層元素監(jiān)聽(tīng)到。所以如果你想在容器上統(tǒng)一處理多個(gè)子元素的焦點(diǎn)事件記得把監(jiān)聽(tīng)模式指定為捕獲否則事件根本到不了你這里。類(lèi)似的還有mouseenter和mouseleave它們本身也不會(huì)冒泡。mouseover和mouseout會(huì)冒泡但行為表現(xiàn)又完全不同。這些細(xì)節(jié)非常影響交互體驗(yàn)建議你花點(diǎn)時(shí)間把這些成對(duì)事件都試一遍。2. 事件監(jiān)聽(tīng)三種綁定方式與參數(shù)細(xì)節(jié)2.1 onXxx 與 addEventListener 的本質(zhì)區(qū)別給元素綁定事件有三種常見(jiàn)方式直接在 HTML 屬性里寫(xiě)onclickfn()、在 JavaScript 里給元素對(duì)象的onclick屬性賦值、或者使用addEventListener。前兩種在底層邏輯上其實(shí)是同一套機(jī)制元素身上有一個(gè)onclick屬性你給它賦值一個(gè)函數(shù)事件觸發(fā)時(shí)瀏覽器就會(huì)調(diào)用這個(gè)函數(shù)。這種方式簡(jiǎn)單直接但它有一個(gè)典型限制——同一個(gè)元素的同一個(gè)事件只能綁一個(gè)處理函數(shù)后賦值的會(huì)覆蓋前面賦值的。addEventListener就不一樣了。它是標(biāo)準(zhǔn)提供的事件注冊(cè)接口同一個(gè)元素的同一個(gè)事件可以反復(fù)掛載多個(gè)監(jiān)聽(tīng)器它們會(huì)按照綁定的順序依次執(zhí)行。這套機(jī)制帶來(lái)兩個(gè)巨大好處一是可以在不破壞已有邏輯的前提下做能力增強(qiáng)二是配合命名函數(shù)還可以在后續(xù)精確移除某個(gè)監(jiān)聽(tīng)器。用onXxx方式綁定的函數(shù)在回調(diào)內(nèi)部 this 指向的是元素本身而且瀏覽器還會(huì)隱式傳入一個(gè) event 對(duì)象作為參數(shù)。這里有個(gè)小問(wèn)題需要注意讓我理清一下邏輯。onclick屬性綁定的函數(shù)會(huì)在事件觸發(fā)時(shí)由瀏覽器以“事件目標(biāo)”作為 this 來(lái)調(diào)用并傳入事件對(duì)象作為第一個(gè)參數(shù)。這一點(diǎn)很多人會(huì)忽略但它是區(qū)分兩種綁定方式的一個(gè)細(xì)節(jié)。如果你用addEventListener綁定箭頭函數(shù)函數(shù)體里的 this 與元素?zé)o關(guān)使用普通函數(shù)時(shí)才會(huì)是觸發(fā)事件的元素。寫(xiě)組件代碼時(shí)這個(gè)差異會(huì)導(dǎo)致不可預(yù)期的表現(xiàn)。2.2 第三個(gè)參數(shù)的四種寫(xiě)法addEventListener的第三個(gè)參數(shù)可以被傳成布爾值也可以被傳成一個(gè)配置對(duì)象。布爾值true表示在捕獲階段觸發(fā)監(jiān)聽(tīng)器false表示在冒泡階段觸發(fā)默認(rèn)不傳就相當(dāng)于false。多數(shù)情況下我們綁定事件都是冒泡模式所以寫(xiě)不寫(xiě)都行但一旦你在某些庫(kù)或者框架源碼里看到true就要意識(shí)到這是在捕獲階段做的處理。配置對(duì)象則提供了更豐富的控制能力最常用的有三個(gè)字段capture和傳布爾值的含義相同指定是否在捕獲階段觸發(fā)。once設(shè)為true時(shí)監(jiān)聽(tīng)器執(zhí)行一次之后會(huì)被自動(dòng)移除。passive設(shè)為true時(shí)明確告訴瀏覽器這個(gè)監(jiān)聽(tīng)器不會(huì)調(diào)用preventDefault瀏覽器可以放心地立即執(zhí)行默認(rèn)行為不需要等待監(jiān)聽(tīng)器返回。passive是我非常推薦優(yōu)先考慮的參數(shù)尤其在touchstart、touchmove這類(lèi)滾動(dòng)相關(guān)事件上。移動(dòng)端頁(yè)面如果監(jiān)聽(tīng)touchmove卻不在監(jiān)聽(tīng)器里調(diào)用preventDefault可以把這個(gè)參數(shù)設(shè)為true頁(yè)面滾動(dòng)會(huì)明顯變得更跟手。不過(guò)要小心一旦把passive設(shè)為true在該監(jiān)聽(tīng)器里調(diào)用preventDefault會(huì)被瀏覽器忽略并且控制臺(tái)會(huì)輸出一個(gè)警告。正確的習(xí)慣是在監(jiān)聽(tīng)滾動(dòng)類(lèi)事件時(shí)先想清楚我到底需不需要阻止默認(rèn)行為做不了判斷的時(shí)候就按passive: true處理需要時(shí)再顯式設(shè)為false。once更是事件綁定里被低估的利器。以前的寫(xiě)法是回調(diào)里調(diào)一次removeEventListener把自己移除現(xiàn)在一個(gè)字段就能實(shí)現(xiàn)而且兼容性已經(jīng)非常好。做彈窗關(guān)閉、一次性引導(dǎo)動(dòng)畫(huà)這類(lèi)交互時(shí)once: true可以省不少代碼。2.3 事件監(jiān)聽(tīng)器里的 this 指向與移除時(shí)機(jī)用普通函數(shù)綁定事件時(shí)this 指向觸發(fā)事件的元素。我以前也犯過(guò)這樣的錯(cuò)把組件實(shí)例方法直接傳給addEventListener回調(diào)里以為 this 是組件對(duì)象結(jié)果拿到的是 DOM 元素運(yùn)行時(shí)報(bào)錯(cuò)才反應(yīng)過(guò)來(lái)。解決方式要么是用箭頭函數(shù)在外面包一層要么提前用bind把 this 固定下來(lái)。但是這里有一個(gè)隱蔽的坑如果用bind生成一個(gè)新函數(shù)再傳給addEventListener那這個(gè)新函數(shù)和原函數(shù)并不是同一個(gè)引用后續(xù)removeEventListener時(shí)如果傳的是原函數(shù)監(jiān)聽(tīng)器是移除不掉的。所以在事件綁定初始化時(shí)我一般會(huì)這樣做先把要用的處理函數(shù)存成變量不管后面是不是要移除都保持引用一致。很多內(nèi)存泄漏的問(wèn)題根源就是綁定事件時(shí)用了匿名函數(shù)等到頁(yè)面銷(xiāo)毀、組件卸載時(shí)想移除卻拿不到引用只能眼睜睜看著監(jiān)聽(tīng)器在殘留的 DOM 節(jié)點(diǎn)上掛著。這里千萬(wàn)別忽視 remove 時(shí)機(jī)尤其是單頁(yè)應(yīng)用里頻繁切換路由的場(chǎng)景頁(yè)面組件里 addEventListener 加的監(jiān)聽(tīng)器必須在切換離開(kāi)時(shí)對(duì)應(yīng) remove否則后續(xù)行為會(huì)越來(lái)越詭異頁(yè)面也會(huì)越用越卡。3. 事件對(duì)象開(kāi)發(fā)中最容易混淆的字段與方法3.1 target、currentTarget、relatedTarget 的區(qū)分事件對(duì)象里最容易混淆的就是target和currentTarget。target是真正觸發(fā)事件的那個(gè)元素也就是事件流到達(dá)的最終點(diǎn)currentTarget是當(dāng)前正在執(zhí)行監(jiān)聽(tīng)器的那個(gè)元素。在同一個(gè)事件流里兩者可能相同也可能完全不同。舉個(gè)典型場(chǎng)景一個(gè)列表容器綁定了點(diǎn)擊監(jiān)聽(tīng)器你點(diǎn)擊列表里的某個(gè)li此時(shí)target是那個(gè)被點(diǎn)的li而currentTarget是容器本身。只要這個(gè)監(jiān)聽(tīng)器是通過(guò)容器綁定并觸發(fā)的currentTarget就一直是容器。這也解釋了為什么在事件委托中我們通常通過(guò)target來(lái)獲取真實(shí)點(diǎn)擊的子元素而使用currentTarget來(lái)做元素匹配時(shí)會(huì)失效。因?yàn)闊o(wú)論是點(diǎn)擊哪個(gè)子元素只要監(jiān)聽(tīng)器綁定在容器上currentTarget都不會(huì)變。relatedTarget則是與事件相關(guān)的另一個(gè)元素主要用于focus、blur、mouseenter、mouseleave、mouseover、mouseout這類(lèi)遷移類(lèi)事件。比如mouseover觸發(fā)時(shí)relatedTarget是你剛從哪個(gè)元素移過(guò)來(lái)mouseleave觸發(fā)時(shí)relatedTarget是你即將進(jìn)入哪個(gè)元素。它可能是一個(gè)節(jié)點(diǎn)對(duì)象也可能是null判斷時(shí)要做好空值處理。另外要特別提醒target和currentTarget在不同階段會(huì)變化嗎答案是target在整個(gè)事件流中保持不變因?yàn)樗鞘录嬲齺?lái)源的元素currentTarget則隨著事件經(jīng)過(guò)不同監(jiān)聽(tīng)器而改變。這個(gè)屬性非常適合用來(lái)追蹤當(dāng)前到底是在哪個(gè)節(jié)點(diǎn)上執(zhí)行回調(diào)調(diào)試多級(jí)嵌套組件時(shí)很有價(jià)值。3.2 preventDefault、stopPropagation、stopImmediatePropagation 的用法區(qū)別這三個(gè)方法可以說(shuō)是事件對(duì)象里最重要的一組操作但很多人沒(méi)完整搞清楚它們的分工。preventDefault的作用是阻止瀏覽器執(zhí)行與事件綁定的默認(rèn)行為比如點(diǎn)擊鏈接跳轉(zhuǎn)、提交表單刷新頁(yè)面、在輸入框敲回車(chē)提交數(shù)據(jù)、在文本上點(diǎn)擊出現(xiàn)的選區(qū)等。它不會(huì)阻止事件繼續(xù)傳播也不會(huì)阻止其他監(jiān)聽(tīng)器執(zhí)行。表單校驗(yàn)和前端路由的很多核心邏輯都建立在這個(gè)方法之上。stopPropagation的作用是終止事件在當(dāng)前階段的后續(xù)傳播流程如果當(dāng)前處于捕獲階段則事件不會(huì)再向更內(nèi)層傳遞如果當(dāng)前處于冒泡階段則事件不會(huì)再向更外層傳遞。但它不會(huì)阻止同一個(gè)元素上其他監(jiān)聽(tīng)器的執(zhí)行。這里有個(gè)誤區(qū)很多開(kāi)發(fā)者以為調(diào)用它之后整個(gè)事件就完全靜止了而實(shí)際上同元素上后續(xù)綁定的監(jiān)聽(tīng)器還是會(huì)觸發(fā)只是事件到不了別的元素而已。stopImmediatePropagation是升級(jí)版它在終止傳播的同時(shí)還會(huì)阻止當(dāng)前元素上后續(xù)所有監(jiān)聽(tīng)器的執(zhí)行。如果你的目標(biāo)是一個(gè)監(jiān)聽(tīng)器執(zhí)行后同元素上的其他監(jiān)聽(tīng)器全都不要觸發(fā)了就必須用它。在一些全局?jǐn)r截場(chǎng)景里比如點(diǎn)擊遮罩層時(shí)既要阻止冒泡又要讓其他邏輯全都不要執(zhí)行這個(gè)方法非常有用。我在實(shí)際項(xiàng)目中總結(jié)出一個(gè)原則能用preventDefault解決的不要用stopPropagation能用stopPropagation解決的不要用stopImmediatePropagation。因?yàn)檫^(guò)度阻斷事件傳播會(huì)影響其他功能的正常運(yùn)行尤其是很多公共組件依賴事件冒泡來(lái)做統(tǒng)計(jì)采集或全局交互你多阻斷一層別人就多一個(gè)排查成本。3.3 事件對(duì)象常用字段速查我把平時(shí)高頻使用的事件對(duì)象字段整理成一個(gè)速查表方便大家快速查閱。字段含義典型使用場(chǎng)景type事件類(lèi)型字符串如click、keydown一個(gè)監(jiān)聽(tīng)器處理多種事件時(shí)做分支判斷target事件真正觸發(fā)的目標(biāo)元素事件委托中確定實(shí)際被操作的元素currentTarget當(dāng)前正在執(zhí)行監(jiān)聽(tīng)器的元素判斷回調(diào)運(yùn)行所處的節(jié)點(diǎn)relatedTarget關(guān)聯(lián)元素遷移類(lèi)事件使用判斷鼠標(biāo)從哪來(lái)、到哪去eventPhase當(dāng)前所處的傳播階段(1/2/3)調(diào)試捕獲、目標(biāo)、冒泡階段行為clientX/clientY鼠標(biāo)相對(duì)視口的坐標(biāo)實(shí)現(xiàn)自定義拖動(dòng)、氣泡面板跟隨pageX/pageY鼠標(biāo)相對(duì)整個(gè)頁(yè)面的坐標(biāo)處理長(zhǎng)頁(yè)面下的定位計(jì)算key/code鍵盤(pán)按鍵信息快捷鍵匹配避免 keyCode 判斷button鼠標(biāo)按鍵值(0/1/2)區(qū)分左右鍵點(diǎn)擊實(shí)現(xiàn)右鍵菜單detail點(diǎn)擊次數(shù)雙擊與單擊的區(qū)分touches當(dāng)前觸摸點(diǎn)列表多點(diǎn)觸控手勢(shì)識(shí)別deltaY/deltaX滾輪滾動(dòng)量自定義滾動(dòng)行為、縮放控制這里特別要提一下detail字段。瀏覽器會(huì)通過(guò)該字段記錄點(diǎn)擊的次數(shù)單擊時(shí)值為 1雙擊時(shí)值為 2。但由于單擊和雙擊是同一個(gè)事件類(lèi)型多次觸發(fā)你在監(jiān)聽(tīng)click時(shí)不能簡(jiǎn)單判斷detail 2就實(shí)現(xiàn)雙擊邏輯因?yàn)檫@期間單擊事件也已經(jīng)觸發(fā)一次了。正規(guī)的做法是使用dblclick事件或者在單擊回調(diào)里做防抖延遲等一段時(shí)間確認(rèn)用戶沒(méi)有繼續(xù)點(diǎn)擊。4. 事件類(lèi)型全景高頻場(chǎng)景與容易被忽略的事件4.1 鼠標(biāo)與指針事件鼠標(biāo)事件是瀏覽器交互的基石日常開(kāi)發(fā)中最常用的有click、dblclick、mousedown、mouseup、mousemove、mouseover、mouseout、mouseenter、mouseleave、contextmenu。它們之間的關(guān)系很多人沒(méi)有系統(tǒng)梳理過(guò)一次完整的點(diǎn)擊行為實(shí)際是mousedown → mouseup → click連發(fā)三炮dblclick是在兩次click之后觸發(fā)但觸發(fā)時(shí)機(jī)在不同瀏覽器里略有差異。在鼠標(biāo)事件里最容易踩的坑是mouseover和mouseout與mouseenter和mouseleave的差異。前兩者會(huì)冒泡并且子元素進(jìn)入或離開(kāi)時(shí)都會(huì)觸發(fā)父元素的mouseover/mouseout導(dǎo)致頻率極高、邏輯容易誤判后兩者不冒泡只有指針進(jìn)入或離開(kāi)元素自身邊界時(shí)才會(huì)觸發(fā)。寫(xiě)下拉菜單、懸停浮層、Tooltip 這類(lèi)交互時(shí)我會(huì)默認(rèn)優(yōu)先使用mouseenter和mouseleave因?yàn)樗鼈兊男袨楦现庇X(jué)也省去了手動(dòng)處理子元素干擾的麻煩。指針事件是更現(xiàn)代的一套統(tǒng)一方案pointerdown、pointermove、pointerup等把鼠標(biāo)、觸摸、手寫(xiě)筆統(tǒng)一成一類(lèi)事件。最明顯的優(yōu)勢(shì)是通過(guò)pointerType字段可以判斷操作類(lèi)型是鼠標(biāo)還是觸摸再配合setPointerCapture方法可以實(shí)現(xiàn)跨元素拖動(dòng)而不丟失事件。這里有個(gè)值得注意的細(xì)節(jié)pointerdown和mousedown的觸發(fā)順序有區(qū)別默認(rèn)情況下先觸發(fā)指針事件再觸發(fā)鼠標(biāo)事件。如果你在同一個(gè)元素上同時(shí)監(jiān)聽(tīng)兩類(lèi)事件做操作時(shí)要警惕同一交互流程被執(zhí)行兩次。4.2 鍵盤(pán)與輸入事件鍵盤(pán)事件里keydown、keypress、keyup三者曾經(jīng)存在較大兼容分歧現(xiàn)在普遍推薦使用keydown和keyup。判定按鍵時(shí)也應(yīng)盡量避免使用已經(jīng)被廢棄的keyCode而是優(yōu)先使用event.key或event.code。key返回的是按鍵對(duì)應(yīng)的字符值比如a、Enter、ArrowUpcode返回的是按鍵在鍵盤(pán)上的物理位置比如KeyA不管輸出的是 a 還是其他語(yǔ)言字符都返回KeyA。做國(guó)際化和多鍵盤(pán)布局支持時(shí)code更穩(wěn)定做邏輯判斷時(shí)則通常用key更直觀。表單場(chǎng)景里還有一組輸入類(lèi)事件需要注意input、change、focus、blur。input在輸入框內(nèi)容每次變化時(shí)觸發(fā)適合做實(shí)時(shí)搜索、字?jǐn)?shù)統(tǒng)計(jì)change在內(nèi)容改變且失焦或提交時(shí)觸發(fā)適合做校驗(yàn)和最終提交。移動(dòng)端輸入法選詞時(shí)input事件的觸發(fā)時(shí)機(jī)和桌面端存在差異做實(shí)時(shí)反饋時(shí)建議用input而不是keydown因?yàn)閗eydown捕捉的是物理按鍵不是輸入內(nèi)容。剪貼板事件copy、cut、paste也是常被忽視的類(lèi)型。除了做富文本編輯器的粘貼格式化還可以利用event.clipboardData讀取或修改剪貼板內(nèi)容。不過(guò)瀏覽器對(duì)剪貼板的訪問(wèn)有權(quán)限限制非用戶主動(dòng)操作時(shí)讀取clipboardData會(huì)得到空值。實(shí)現(xiàn)點(diǎn)擊按鈕復(fù)制鏈接這類(lèi)需求時(shí)我會(huì)優(yōu)先使用異步剪貼板 APInavigator.clipboard.writeText而不是構(gòu)造隱藏輸入框加document.execCommand(copy)的古老方案。4.3 其他容易忽略但關(guān)鍵時(shí)刻很有用的高頻事件文檔和窗口級(jí)別也有一批實(shí)用事件。DOMContentLoaded在 HTML 解析完成后立即執(zhí)行不需要等待樣式表、圖片和腳本全部加載完畢適合初始化頁(yè)面內(nèi)的事件綁定和狀態(tài)設(shè)置。load則要等頁(yè)面完整加載完畢包括所有資源適合做需要依賴圖片尺寸來(lái)計(jì)算布局的場(chǎng)景。這兩個(gè)事件的時(shí)機(jī)差異直接影響頁(yè)面白屏?xí)r間和用戶可交互時(shí)間。滾動(dòng)相關(guān)事件scroll與resize屬于高頻觸發(fā)事件它們本身不會(huì)冒泡但可以在document或window上通過(guò)捕獲模式監(jiān)聽(tīng)。scroll與resize每次都可能導(dǎo)致大量的布局計(jì)算所以在監(jiān)聽(tīng)器內(nèi)部務(wù)必使用requestAnimationFrame、節(jié)流或防抖來(lái)控制執(zhí)行頻率。尤其是移動(dòng)端scroll的觸發(fā)頻率非常高如果不做性能限制很容易導(dǎo)致頁(yè)面卡頓。還有一個(gè)容易被忽略的是visibilitychange事件它會(huì)在瀏覽器標(biāo)簽頁(yè)切換、應(yīng)用切后臺(tái)、屏幕鎖定時(shí)觸發(fā)。做在線視頻平臺(tái)時(shí)這個(gè)事件是播放器暫停和恢復(fù)邏輯的依據(jù)比f(wàn)ocus、blur更可靠因?yàn)閎lur在很多移動(dòng)端瀏覽器上并不會(huì)穩(wěn)定觸發(fā)。頁(yè)面統(tǒng)計(jì)在線用戶的場(chǎng)景里也經(jīng)常用這個(gè)事件來(lái)判斷用戶是否真在瀏覽器上。5. 事件委托少寫(xiě)一半監(jiān)聽(tīng)器的核心技巧5.1 事件委托的原理事件委托建立在冒泡機(jī)制之上。把監(jiān)聽(tīng)器綁定在一個(gè)父級(jí)容器上通過(guò)事件對(duì)象的target屬性判斷實(shí)際觸發(fā)事件的子元素再執(zhí)行對(duì)應(yīng)邏輯這樣就不需要在每個(gè)子元素上單獨(dú)綁定事件了。最經(jīng)典的應(yīng)用是列表操作頁(yè)面上有一個(gè)動(dòng)態(tài)生成的列表每個(gè)項(xiàng)里都有編輯、刪除按鈕如果給每個(gè)按鈕單獨(dú)綁定事件新增一個(gè)列表項(xiàng)就要重新綁定一次使用委托后只需要給整個(gè)列表容器綁定一次監(jiān)聽(tīng)器新加入的子元素自動(dòng)就能響應(yīng)事件。這里有一個(gè)經(jīng)驗(yàn)性的判斷如果某個(gè)容器里存在大量結(jié)構(gòu)相同、行為相似的子元素或者子元素是動(dòng)態(tài)增刪的事件委托一定是首選方案。我自己在做后臺(tái)管理系統(tǒng)時(shí)很多表格和卡片列表的交互都用事件委托實(shí)現(xiàn)但要小心同一個(gè)容器里不同類(lèi)型按鈕做了不同操作的情況。為了快速判斷用戶點(diǎn)了哪個(gè)按鈕我通常會(huì)在按鈕上加>const doneEvent new CustomEvent(task:finished, { detail: { taskId: 1024, success: true }, bubbles: true }); document.querySelector(#main)?.dispatchEvent(doneEvent);這里需要注意的是bubbles參數(shù)如果想讓自定義事件也能像原生事件一樣在 DOM 里冒泡必須把它顯式設(shè)為true。很多人第一次寫(xiě)自定義事件時(shí)會(huì)忽略這個(gè)字段結(jié)果在其他父節(jié)點(diǎn)上監(jiān)聽(tīng)不到事件排查半天才發(fā)現(xiàn)是冒泡沒(méi)開(kāi)。dispatchEvent的觸發(fā)方式也有個(gè)明顯特點(diǎn)它是同步的也就是說(shuō)拋出事件后監(jiān)聽(tīng)器會(huì)在后續(xù)代碼執(zhí)行前立即運(yùn)行寫(xiě)的時(shí)候要留意會(huì)不會(huì)造成執(zhí)行順序上的意外。6.2 自定義事件在組件通信中的應(yīng)用之前做一套模擬面試打分系統(tǒng)時(shí)我采用過(guò)一個(gè)基于自定義事件的架構(gòu)界面被拆成題目面板、計(jì)時(shí)器、評(píng)分表單、結(jié)果總覽等多個(gè)互不依賴模塊任何一個(gè)模塊都不直接引用其他模塊的實(shí)例模塊之間通過(guò)自定義事件溝通。比如題目切換時(shí)題目面板拋出quiz:change事件計(jì)時(shí)器模塊監(jiān)聽(tīng)該事件重置時(shí)間提交評(píng)分時(shí)評(píng)分表單拋出quiz:complete結(jié)果總覽模塊監(jiān)聽(tīng)后匯總數(shù)據(jù)并渲染結(jié)果。現(xiàn)在很多 MVC 和組件化框架雖然底層通信機(jī)制不同但思想上是相通的。這樣設(shè)計(jì)的好處是新增一個(gè)模塊時(shí)完全不用改動(dòng)已有模塊的代碼只需要讓新模塊監(jiān)聽(tīng)自己關(guān)心的事件即可。原來(lái)用回調(diào)函數(shù)或者直接調(diào)用兄弟組件方法時(shí)每次需求變更都要沿著調(diào)用鏈找到所有關(guān)聯(lián)方使用自定義事件后這種維護(hù)成本顯著下降。缺點(diǎn)是大量使用自定義事件會(huì)讓代碼里的隱形鏈路變多排查問(wèn)題時(shí)不如直接函數(shù)調(diào)用直觀所以我的使用原則是只在跨模塊業(yè)務(wù)流和需要多個(gè)模塊同時(shí)做出反應(yīng)的場(chǎng)景中使用普通父子通信該用 props 或者回調(diào)還是直接用。6.3 事件冒泡、composed 與瀏覽器原生事件的關(guān)聯(lián)自定義事件與原生事件還有一個(gè)聯(lián)動(dòng)用法在原生事件回調(diào)里組織數(shù)據(jù)后拋出一個(gè)新的自定義事件讓上層組件只關(guān)注業(yè)務(wù)動(dòng)作而不是操心具體是單擊、觸摸還是回車(chē)觸發(fā)的。這里涉及一個(gè)composed參數(shù)它決定自定義事件能否穿過(guò) Shadow DOM 邊界。如果你在使用 Web Components 或者瀏覽器原生組件的 Shadow DOM想在外層捕獲組件內(nèi)部拋出的自定義事件需要同時(shí)設(shè)置bubbles: true和composed: true少一個(gè)都傳不出去。另外還有一個(gè)常被忽略的細(xì)節(jié)通過(guò)element.dispatchEvent()發(fā)出的自定義事件在事件對(duì)象的event.target上就是調(diào)用dispatchEvent的那個(gè)元素而且事件流會(huì)從該元素開(kāi)始正常傳播。也就是說(shuō)自定義事件和原生事件在傳播模型上是完全一致的冒泡、捕獲、委托這些概念都能用在自定義事件上。這也意味著你可以把自定義事件從容器里委托到更上層處理全局業(yè)務(wù)監(jiān)控和用戶行為統(tǒng)計(jì)這類(lèi)功能完全可以建立在自定義事件體系上。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄7.1 事件重復(fù)綁定與內(nèi)存泄漏事件相關(guān)的內(nèi)存泄漏絕大多數(shù)都指向同一個(gè)原因監(jiān)聽(tīng)器加了但沒(méi)被移除。我排查過(guò)的一個(gè)典型場(chǎng)景是頁(yè)面里有個(gè)彈窗組件每次打開(kāi)時(shí)都會(huì)給window綁定一個(gè)resize監(jiān)聽(tīng)器用來(lái)做窗口尺寸適配但關(guān)閉彈窗時(shí)沒(méi)有移除。用戶來(lái)回打開(kāi)關(guān)閉幾次后resize監(jiān)聽(tīng)器越積越多每調(diào)整一次窗口大小所有歷史監(jiān)聽(tīng)器全部執(zhí)行頁(yè)面越來(lái)越卡最后還會(huì)引發(fā)奇怪的重疊位移。排查這類(lèi)問(wèn)題我用的是兩種方式。第一種在 Chrome DevTools 的 Performance 面板里錄制一段交互觀察事件監(jiān)聽(tīng)器數(shù)量和內(nèi)存曲線第二種直接在getEventListeners(window)里查看當(dāng)前對(duì)象上掛載的所有監(jiān)聽(tīng)器。只要看到一個(gè)元素上監(jiān)聽(tīng)器數(shù)量明顯多于預(yù)期基本就定位到了問(wèn)題源。修復(fù)方式就是在清理函數(shù)里使用與addEventListener完全一致的函數(shù)引用調(diào)用removeEventListener并保證第三個(gè)參數(shù)與綁定時(shí)的capture值一致。這里特別容易出錯(cuò)的地方是removeEventListener的第三個(gè)參數(shù)雖然通常只關(guān)心capture是否一致但如果你用配置對(duì)象綁定的時(shí)候還加過(guò)once、passive等選項(xiàng)移除時(shí)只需要匹配capture字段即可其他字段不用也傳。講到內(nèi)存泄漏還要提醒一個(gè)綁定位置的問(wèn)題在forEach循環(huán)里給每個(gè)子元素都綁定了click事件但其中有些元素是動(dòng)態(tài)生成的綁定時(shí)直接寫(xiě)了個(gè)匿名函數(shù)后續(xù)根本無(wú)法移除。我的習(xí)慣是凡是在循環(huán)體里綁定事件都要先把處理函數(shù)提取為命名函數(shù)防止事件清除時(shí)找不到引用。習(xí)慣了提煉命名函數(shù)后代碼結(jié)構(gòu)本身也會(huì)更清爽。7.2 高頻事件觸發(fā)與頁(yè)面性能mousemove、scroll、resize這類(lèi)事件在一秒內(nèi)可能觸發(fā)幾十次如果監(jiān)聽(tīng)器里做了大量 DOM 操作或者復(fù)雜計(jì)算頁(yè)面性能會(huì)直線下降。優(yōu)化方案一般在節(jié)流和防抖之間做選擇。節(jié)流意味著固定周期只執(zhí)行一次適合拖拽實(shí)時(shí)反饋這類(lèi)持續(xù)行為防抖意味著事件停止觸發(fā)后的一小段時(shí)間才執(zhí)行適合搜索輸入、窗口停止?jié)L動(dòng)后再觸發(fā)計(jì)算這類(lèi)場(chǎng)景。需要強(qiáng)調(diào)的是節(jié)流不是防抖的替代品用錯(cuò)了會(huì)讓拖拽行為的響應(yīng)延遲或者搜索框的提示異常滯后。在功能簡(jiǎn)單但追求極致流暢的場(chǎng)景下我還會(huì)使用requestAnimationFrame來(lái)配合高頻事件它能把操作天然同步到瀏覽器的下一次繪制之前避免同一幀內(nèi)做重復(fù)計(jì)算。后面如果瀏覽器兼容性允許你還可以考慮把高頻事件的監(jiān)聽(tīng)器本身改成 passive用第 2 節(jié)提到的方式減輕滾動(dòng)類(lèi)事件的壓力。這幾個(gè)優(yōu)化手段可以組合使用優(yōu)先級(jí)是先確認(rèn)監(jiān)聽(tīng)器里沒(méi)有高開(kāi)銷(xiāo)邏輯再做觸發(fā)頻率控制。7.3 動(dòng)態(tài)元素綁定不上事件的處理動(dòng)態(tài)生成的元素綁定事件沒(méi)有效果是一個(gè)高頻求助問(wèn)題。核心原因很簡(jiǎn)單綁定事件時(shí)元素還不存在或者是監(jiān)聽(tīng)器沒(méi)有被正確委托。正確做法是讓父級(jí)元素通過(guò)冒泡機(jī)制接管這些動(dòng)態(tài)子元素的事件處理也就是事件委托。這里我建議在首次渲染和每次動(dòng)態(tài)插入后都維護(hù)同一套委托入口避免不必要的臨時(shí)綁定。在 Vue、React 這類(lèi)框架里框架渲染 DOM 的路由邏輯往往和原生事件體系有隔離你怎么調(diào)框架 API 都不會(huì)觸發(fā)原始的addEventListener綁定需求。所以遇到動(dòng)態(tài)列表數(shù)據(jù)更新后事件不生效的問(wèn)題優(yōu)先檢查是不是框架的渲染時(shí)機(jī)和綁定時(shí)機(jī)不匹配而不是直接懷疑事件綁定失效。React 的合成事件機(jī)制在底層會(huì)把大部分事件委托到根容器上這時(shí)如果發(fā)現(xiàn)自定義事件和原生事件混用導(dǎo)致行為不一致我會(huì)先在框架的生命周期里做統(tǒng)一初始化邏輯盡量避免在渲染中途直接操作 DOM 節(jié)點(diǎn)。7.4 瀏覽器差異與兼容策略現(xiàn)在主流瀏覽器對(duì) DOM 事件標(biāo)準(zhǔn)支持已經(jīng)比較統(tǒng)一但某些邊緣情況依然存在差異。比如KeyboardEvent的key、code、keyCode在中文輸入法候選框打開(kāi)時(shí)的返回值差異很大移動(dòng)端觸摸與鼠標(biāo)事件的觸發(fā)順序也各有不同。開(kāi)發(fā)跨端項(xiàng)目時(shí)我會(huì)約定優(yōu)先使用事件類(lèi)型更穩(wěn)定的規(guī)范寫(xiě)法比如使用click作為觸摸和鼠標(biāo)操作的統(tǒng)一響應(yīng)事件再通過(guò)pointer事件做精細(xì)化手感增強(qiáng)而不是同時(shí)監(jiān)聽(tīng)touchstart和click導(dǎo)致同一個(gè)操作被觸發(fā)兩次。另外持續(xù)監(jiān)聽(tīng)beforeunload事件時(shí)不同的瀏覽器對(duì)返回值處理邏輯也有細(xì)微差別有些需要顯式設(shè)置event.preventDefault()并設(shè)置returnValue舊屬性才能彈出離開(kāi)確認(rèn)提示。這類(lèi)兼容性處理沒(méi)有統(tǒng)一的口徑我的經(jīng)驗(yàn)是每次做完兼容適配都在代碼注釋里留一份說(shuō)明避免后續(xù)維護(hù)的人再把兼容邏輯刪掉。最后分享兩個(gè)小技巧第一個(gè)建議是碰到事件相關(guān)的疑難雜癥先不要在代碼里到處打日志打開(kāi) DevTools 的 Elements 面板選中目標(biāo)節(jié)點(diǎn)在 Console 里輸入getEventListeners(document.querySelector(...))一眼就能看清這個(gè)節(jié)點(diǎn)上掛的所有監(jiān)聽(tīng)器來(lái)源。這個(gè)指令真的幫我節(jié)省了大量排查時(shí)間。第二個(gè)建議是如果業(yè)務(wù)規(guī)格書(shū)里的交互邏輯比較復(fù)雜可以先用偽代碼把事件觸發(fā)的順序和互斥關(guān)系寫(xiě)出來(lái)再動(dòng)手編碼。事件系統(tǒng)里最難的不在 API而在多個(gè)事件之間協(xié)作后的狀態(tài)變化。規(guī)格先理清代碼就穩(wěn)了。