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