你有沒有看過新人開發者為一個點擊事件不觸發抓狂？

然后他們像噴驅蟲劑一樣在代碼里加上 stopPropagation()，就此收工。

但事情從來沒有那么簡單。

其實也不能怪他們。大多數前端開發者只是學了一點點事件冒泡的知識，剛好讓功能跑起來，就急匆匆進入下一個任務，絲毫沒有意識到——

瀏覽器其實正在它們的 UI 背后搭建一個復雜的連鎖反應裝置。直到某一天，它爆炸了。

這次來聊聊那個“人人都以為自己懂”的東西，事件冒泡。

來點沒人要求的復習

瀏覽器中的事件傳播有兩個階段：

• 捕獲階段（capturing phase）：事件從 document 一路向下傳播到目標元素；
• 冒泡階段（bubbling phase）：事件從目標元素向上傳播回根節點。

大部分開發者只熟悉冒泡，因為 addEventListener 默認是在冒泡階段監聽事件。除非你顯式傳入 { capture: true }，否則你始終活在“泡泡里”。

這也是 90% 開發者的操作范圍。沒問題，直到問題真的來了。

冒泡很好用，但一旦忽略它就會出事

想象一個常見場景：

有一個 Modal，Modal 里有個關閉按鈕。點擊 Modal 外的背景層也會關閉 Modal。

<div class="backdrop" onClick="closeModal()">
  <div class="modal">
    <button onClick="doSomething()">點我</button>
  </div>
</div>

看起來沒毛病，對吧？

錯。

點擊 Modal 里的按鈕時，點擊事件會冒泡到背景層，觸發 closeModal()，Modal 被直接關閉了。

現在你的 Modal 成了“點哪都關”。

stopPropagation()：事件處理的“萬能膠帶”

于是開發者的第一反應就是：

加個 stopPropagation()，一勞永逸。

button.addEventListener("click", (e) => {
  e.stopPropagation();
  doSomething();
});

問題解決了？其實沒有。

幾個月后，某個功能壞了，誰也搞不清事件為什么沒觸發。因為某個神秘的事件，悄無聲息地死在了冒泡路上，而未來的你只剩下調試的頭痛。

捕獲階段：被遺忘的那一半

我們聊聊那半邊你幾乎從未用過的機制：

element.addEventListener("click", handler, { capture: true });

表示你的處理器將在事件到達目標元素之前就被調用。

這有用嗎？非常。

但幾乎沒人用。

比如：你需要在任何元素接收到點擊之前記錄分析數據，或者做權限攔截。這些事在冒泡階段已經來不及了。

捕獲階段，才是插隊的地方。

passive 監聽器：沉默的性能殺手

現代瀏覽器允許你用 passive: true 標記監聽器：

element.addEventListener("touchmove", handler, { passive: true });

告訴瀏覽器：“我不會調用 preventDefault()，可以放心優化滾動性能。”

如果你撒謊了呢？

瀏覽器會報 warning。嚴重時，頁面滾動會變卡，但你可能 QA 提 Bug 才會發現。

事件處理的性能細節，往往藏在這些看似無關緊要的小參數里。

進入事件地獄的循環

現在加上 setTimeout、async/await、組件重渲染、React 的 synthetic event……

突然間你處理的事件，已經不是原始 DOM 事件了，而是一個層層封裝的“幻想事件”。

有沒有試過對 React 事件調用 preventDefault() 但根本不起作用？那是因為 React 事件是復用的，你得 event.persist() 才能保留它。

我們在冒泡系統之上又搭建了一套更復雜的事件系統。會出事嗎？當然會。

最后的思考：這件事至今仍重要

前端開發已經很復雜了。

大家不斷堆框架、加抽象層，而底層的事件機制，從 2000 年代起就幾乎沒怎么變過。

可我們仍然用錯它。

我們不教冒泡的本質，不講捕獲的意義，把 stopPropagation() 當成修復工具，而不是危險信號。

然后再來抱怨：為什么 UI 表現得像鬼屋一樣。

如果在構建一個真正的前端應用，尤其是涉及嵌套組件、自定義事件的時候，理解事件機制，已經不是“加分項”，而是基本素養。

因為瀏覽器并不在乎你用的是哪套現代框架。

它只管一件事：

它還在冒泡。