DOM操作与事件委托实战：从冒泡机制到动态列表的完整指南-二趣网

说实话，前端写久了你会发现，很多看起来"花里胡哨"的问题，本质都绕不开三个基本功：DOM、事件冒泡和事件委托。这不是面试官用来刁难人的八股文，而是你每次点击、滚动、输入背后真正发生的事。

这次就结合我这几年写业务代码的真实经历，把"页面元素操作、事件冒泡、事件委托"一次性掰开揉碎。我会从最基础的 DOM 获取元素讲起，再到事件传播机制的底层逻辑，最后用一整套可复制的实战代码，把我踩过的那些冒泡的坑、委托的边界条件，以及如何优雅地处理动态列表，都毫无保留地分享出来。

文章不堆砌概念，只讲人话、讲实操。不管你现在是刚入门前端的新人，还是准备面试想补全知识盲区，又或者是写业务代码经常跟 DOM 事件较劲的开发者，这篇都值得你花 10 分钟看完。

1. 先搞懂 DOM：从"找元素"到"改页面"的完整套路

很多人写 DOM 操作都是"查一下文档、复制一下代码"，但真到排查问题时，连"我到底拿没拿到这个元素"都说不好。这里我先带你把最核心的 DOM 操作过一遍，知道工具在哪、怎么用、什么时候该用哪个，后面做事件处理才不慌。

1.1 获取元素的几种姿势，谁快谁慢

获取元素是 DOM 操作的起点。我见过不少新手，全程只用document.querySelector，不是因为其他 API 不好用，而是压根不知道有更精准的替代方案。

我把常用的获取方式整理成一张对比表，你平时直接照着选就行：

方法	返回内容	典型场景	备注
`getElementById`	单个元素	有明确 id 的核心节点	最快，没有之一
`getElementsByClassName`	类数组的 HTMLCollection	同一类样式的容器	动态集合，DOM 一变它就变
`querySelectorAll`	静态 NodeList	需要按选择器匹配一组节点	灵活，但性能略低于 ID 查询
`querySelector`	单个元素	需要复杂选择器时	用得好可以少写很多遍历
`closest`	单个祖先元素	委托中找目标容器	配合事件用途极大，后面会讲

举个直观的例子：

<ul id="list"> <li class="item">// 获取整个列表 const list = document.getElementById('list'); // 获取所有 li，返回一个类数组 const itemsThroughClass = list.getElementsByClassName('item'); // 获取所有 li，返回 NodeList，可用 forEach const itemsThroughQuery = list.querySelectorAll('.item'); // 获取第一个 li const firstItem = list.querySelector('.item');

有一个隐藏点很多人踩过：getElementsByClassName返回的是HTMLCollection（动态集合），而querySelectorAll返回的是NodeList（静态快照）。如果你先拿到一个 HTMLCollection，随后往 DOM 里新增了一个匹配元素，这个集合的长度会自动变大。对于不熟悉这个特性的人来说，在 for 循环里遍历getElementsByClassName的时候，很容易因为"集合长度不断变化"导致死循环或逻辑错乱。所以我在大多数业务场景下更倾向使用querySelectorAll，它生成的是静态列表，行为更可控。

1.2 改内容、改样式、改属性的常用手段

拿到元素之后，紧接着就是"改"。改的内容无外乎这么几类：

第一，改文本和 HTML 结构

element.innerText：只处理可见文本，会触发回流，性能差一点，但直观。
element.textContent：处理所有文本，包括隐藏节点里的文字。性能比 innerText 略好。
element.innerHTML：把字符串当作 HTML 解析。能用它，但别拿它拼用户输入，否则就是 DOM 型 XSS 的温床——这个热搜词你也看到了。

如果你的数据含用户输入，保存时要么用textContent纯文本展示，要么先把特殊字符转义。以下是一个典型的"安全教训"：

// 危险写法：用户输入会被当成 HTML 执行 container.innerHTML = '<div>' + userInput + '</div>'; // 安全写法：只当文本存在，标签会被转义，不会执行 container.textContent = userInput;

第二，改样式

样式操作不只是el.style.color = 'red'这么简单。真正项目里，我会做两件事：

把"显示/隐藏""高亮/正常"这类状态，尽量抽象成 CSS 类名，然后用classList.add/remove/toggle切换。这样外观逻辑都收敛在 CSS 里，JS 只负责状态切换。
对于频繁修改的动画属性，可以考虑requestAnimationFrame合并操作。比如快速滚动时更新一个元素的位置，如果每次 scroll 都直接改style.top，浏览器可能来不及应对，最终看起来就是卡顿。

// 推荐：状态与样式分离 const box = document.querySelector('.box'); box.classList.toggle('active'); // 直接改样式适合临时调试 box.style.transform = 'translateX(120px)';

第三，改属性和自定义数据

标准属性用setAttribute/getAttribute或者直接el.id = 'xxx'；自定义数据用dataset，对应 HTML 里的>document.querySelectorAll('.item').forEach((el, index) => { el.dataset.index = index; }); // 在事件处理里直接读 function handleItemClick(e) { const li = e.target.closest('li'); console.log(li.dataset.index); // 拿到序号 }

1.3 为什么我建议你少用 innerHTML 拼结构

讲 DOM 操作，有一件事必须单独拎出来说：少用innerHTML去拼接长串 HTML，尤其是在列表渲染和事件绑定结合的场景里。

我见过一个实际线上问题：每隔两秒轮询接口，把返回的列表用innerHTML重新渲染，然后里面的按钮用了内联onclick绑定事件。看起来没问题，但有两个副作用：

每次innerHTML重绘，整个列表的 DOM 都被销毁重建，按钮的监听器也跟着没了。如果内联事件是第一次渲染时绑定的，等第二次渲染之后，这个按钮是全新节点，必须重新绑定。
如果数据里混入了未转义的引号或尖括号，页面结构可能直接崩掉。

所以现在我的习惯是：能拆成数据用 map 生成，绝不硬拼 HTML 字符串；必须在插入后用事件委托管理交互，绝不靠内联 onclick 一条条绑。这样既安全，也省心。

2. 事件机制：绑定、执行顺序和那个总被忽略的事件对象

DOM 操作是"静态"能力，事件才是让页面"活"起来的开关。但事件不是简单地"监听"一下就行，它有一套完整的传播机制。很多线上 bug 查到最后，根因都是没搞清楚事件的传播顺序和event对象里各个字段的含义。

2.1 事件绑定的三种写法和一种推荐

常见的事件绑定有三种：

// 写法一：内联，直接写在 HTML 上 <button onclick="handleClick()">点我</button> // 写法二：on 前缀属性，在 JS 里赋值 btn.onclick = handleClick; // 写法三：addEventListener（推荐） btn.addEventListener('click', handleClick);

为什么推荐写法三？

同一个元素的同一个事件可以挂多个处理函数，onclick只能寄一个，后面的会覆盖前面的。
可以控制事件阶段（捕获或冒泡），可以配合once、passive参数做到只执行一次或优化滚动性能。
在动态添加/移除监听时，removeEventListener才能精准解绑。onclick赋值虽然也能置空，但可读性和灵活性都差一些。

2.2 事件对象里藏着"现场证据"

每个事件处理函数接收到的第一个参数，就是事件对象。老式写法会写event，现代标准里通常写e或evt。新手最容易混淆的是以下两个概念：

e.target：触发事件的最底层元素。在事件冒泡过程中，它始终指向最开始点击的那个节点。
e.currentTarget：当前正在执行事件的元素。因为监听器绑在谁身上，currentTarget就是谁。

举个例子：列表ul上绑定了点击事件，你点了其中的一个li，触发后e.target是那个li或者li里的a标签，而e.currentTarget是ul。这两个字段在事件委托中就是核心工具，先理解清楚，后面代码才不会写错。

除了target，还有几个高频字段：

e.preventDefault()：阻止默认行为，比如表单提交、点击 a 标签跳转。
e.stopPropagation()：阻止事件继续冒泡或捕获。
e.stopImmediatePropagation()：阻断传播，并且连带阻止当前元素上其他同类事件处理函数执行。
e.key：键盘事件里拿键盘值，比如Enter。
e.buttons / e.button：鼠标事件区分按键。

我习惯在排查事件相关 bug 时，第一步就打印一次e的完整对象，看看target和我预期的是不是同一个元素。很多"点击没反应"的问题，最后都发现是e.target指向了内部某个子节点，而不是我以为的外层容器。

2.3 先冒泡还是先捕获，记住这张规律就行

在 W3C 标准里，一个事件从发生到被处理，会经过三个阶段：

捕获阶段：从window（或document）向下传播到目标元素。
目标阶段：事件到达目标元素本身。
冒泡阶段：从目标元素向上传播回window（或document）。

用addEventListener绑定事件时，第三个参数如果传true，监听器会在捕获阶段触发；默认传false，监听器在冒泡阶段触发。

很多人分不清"捕获"和"冒泡"谁先执行，你就记一句话：同一个事件，从上往下找目标的过程是捕获，从目标往回走的过程是冒泡。捕获先到，冒泡后回。

以点击<button>为例，事件传播顺序是：

捕获阶段：document -> html -> body -> ... -> button
目标阶段：在button上触发
冒泡阶段：button -> ... -> body -> html -> document

这段逻辑在"弹窗外关闭""菜单多级展开"等场景里特别关键。比如你在document上监听了点击事件用于关闭弹窗，按钮点击时弹窗刚打开，捕获/冒泡阶段又从button一路传到document，结果就是弹窗刚打开就被关闭了。这就是典型的事件冒泡"闯祸"案例，后面我详细讲。

3. 事件冒泡：有用但也会闯祸，关键是知道它什么时候停

冒泡是事件机制里最"自然"的传播方式，也是最多 bug 的源头。它本身不是坏事，但如果你不知道它在悄悄发生，就会出现一堆莫名其妙的现象。

3.1 冒泡是怎么一路传到 document 的

事件冒泡的规则一句话总结：目标元素触发事件后，会沿着 DOM 树一路向上触发父元素上绑定的同类事件监听器，直到最顶层。

这是默认行为，不需要你做任何额外设置。比如：

<div id="parent"> <button id="child">点我</button> </div>

const parent = document.getElementById('parent'); const child = document.getElementById('child'); parent.addEventListener('click', () => { console.log('父级收到了点击'); }); child.addEventListener('click', () => { console.log('按钮自己被点击'); });

当你点击按钮时，控制台输出顺序是：

按钮自己被点击 父级收到了点击

你看，child上的监听器先触发，然后事件向上传播，parent的监听器也触发。如果没有第三层、第四层，它会一直传到body、html、document。

这里有个反直觉的点：parent监听器触发时，e.target依然是button，而不是parent。因为"事件从哪发起"决定了target，至于它在冒泡路径上经过了谁，是由 DOM 结构决定的。

3.2 stopPropagation 与 stopImmediatePropagation 的区别

冒泡带来的第一个烦恼是：我不想让父元素的监听器也触发。比如一个卡片本身有跳转详情的事件，卡片里又有个删除按钮，我不希望点删除按钮时触发卡片跳转。

这时候用e.stopPropagation()就能阻断冒泡，事件到目标元素这层就"到此为止"，不会往外传。

但还有一种特殊情况需要stopImmediatePropagation。假如同一个元素上有多个同类事件监听器，例如：

btn.addEventListener('click', fn1); btn.addEventListener('click', fn2); function fn1(e) { e.stopImmediatePropagation(); console.log('fn1'); } function fn2() { console.log('fn2'); // 不会执行 }

stopPropagation只是阻断向外传播，但当前元素上剩下的其他点击监听器依然会执行。stopImmediatePropagation则直接把当前元素上这一类事件的所有监听器全部叫停。理解了这个区别，你才能精准控制"停止的边界"。

3.3 我踩过的冒泡坑：弹窗关闭、菜单联动、统计误报

坑一：弹窗刚打开就被关闭

以前做一个全局消息提示组件，思路是"点页面任意位置，关闭当前提示框"。于是我在document上挂了一个click监听器，用来关弹层。

然后在"显示提示"的按钮上又挂了一个click，用来打开弹层。

问题来了：点击"打开"按钮，按钮的click先触发弹层打开，紧接着事件冒泡到document，document的点击监听器立刻把弹层关了。表面现象是弹层闪一下就没了。

排查思路很简单：先在document监听器里打印e.target，发现是打开按钮，立刻明白是冒泡导致。

修复方案一般有两种：

打开按钮上调用e.stopPropagation()，让事件不再往上冒。
更推荐：document监听器里判断点击点是不是弹层内部，是内部的就不关。这种方法不用牺牲冒泡机制，代码可读性也好。

document.addEventListener('click', (e) => { const dialog = document.getElementById('myDialog'); // 如果点击的是弹层本身或者弹层内部的元素，就不关闭 if (dialog.contains(e.target)) { return; } dialog.style.display = 'none'; });

这两种思路里，第 2 种更优雅，因为不打断其他依赖冒泡的逻辑。

坑二：行点击与列操作的冲突

表格里每一行可以点击展开详情，行内还有一个"删除"链接。如果我只在行上绑了点击监听，没有对"删除"做拦截，用户点删除的时候，删除操作执行完后行点击也会触发，页面就会跳详情页，体验极差。

这是非常典型的业务场景。治理办法不是把行上的监听全部拆掉，而是在处理"删除"的事件函数里e.stopPropagation()，阻断它继续往上冒。

坑三：统计埋点重复上报

公司内部做行为采集，在多个父容器上绑了点击统计，准备统计用户点了哪个区域的按钮。结果发现同样的操作被上报了两遍，页面层级越深，上报次数越多。原因就是冒泡导致同一个事件触发了多个记录点。

这种情况我不建议随便stopPropagation，因为脚本是团队共用的，没人敢保证别的统计代码不依赖冒泡。更好的方案是在埋点 SDK 里做"去重"，或者明确记录e.target的内容，而不是用e.currentTarget的层级元素。

所以说，冒泡不是一个需要"消灭"的机制，而是需要"理解并约束"的机制。什么时候阻止、阻止到哪一层，必须结合业务逻辑来判断，不能一刀切。

3.4 真的需要每次都阻止吗

我必须强调：不要养成"遇事不决 stopPropagation"的习惯。

理由有三：

一旦阻止冒泡，事件委托机制可能失效。比如你把按钮的冒泡阻断了，在外层写的委托逻辑就永远收不到这个点击。
全局监听器无法感知用户行为。有些场景需要统计用户点击全页面的行为，冒泡是你知道"用户到底点了什么"的通道之一。
代码的可维护性下降。别人在后面接手，看到一个 stopPropagation，很难判断你是不是有意为之，万一他需要依赖冒泡，得绕半天。

所以我的建议是：先思考是不是可以通过判断 target 来解决问题，实在不行再阻断，而且阻断范围要尽量小。

4. 事件委托：用最少的事件监听搞定动态列表

说完冒泡，事件委托就顺理成章了。委托的本质就是利用冒泡机制，把子元素的事件监听统一交给父元素来处理。这样无论子元素是本来就有，还是后来动态添加的，都能在一个监听器里被捕获。

4.1 为什么每个按钮挂监听器不是好主意

先看一个反面场景。一个待办事项列表，每行有一个"删除"按钮：

<ul id="todoList"> <li> <span>任务A</span> <button class="delete-btn">删除</button> </li> <li> <span>任务B</span> <button class="delete-btn">删除</button> </li> </ul>

传统写法是：

document.querySelectorAll('.delete-btn').forEach(btn => { btn.addEventListener('click', handleDelete); });

这种写法有两个问题：

当按钮数量很大时（比如几百个），你要创建几百个监听器，每一个都是独立函数，内存开销不小。
当我用 JS 再往列表里插入一行新的<button class="delete-btn">时，新按钮身上没有绑定事件，点它没反应。要重新querySelectorAll一次再绑。这既麻烦又容易漏。

事件委托直接解决以上两个痛点：把监听器挂到父容器ul上，利用冒泡收集所有子元素的点击。新增的按钮只要在ul内部，天然就能触发监听。

4.2 委托的核心实现：target 判定

改写上面的场景：

const todoList = document.getElementById('todoList'); todoList.addEventListener('click', (e) => { // 只处理 <button class="delete-btn"> 的点击 if (e.target.classList.contains('delete-btn')) { const li = e.target.closest('li'); if (li) { li.remove(); } } });

注意，这里我用了e.target而不是e.currentTarget。因为在委托中，监听器是挂在ul上，e.currentTarget永远是ul，只有e.target才是真正被点击的那个按钮。

closest方法在这里作用很大，它会沿 DOM 树向上找匹配选择器的第一个祖先。如果用户没点中按钮，而是点中了文字，e.target可能是span，此时.contains('.delete-btn')为 false，就直接跳过了。

4.3 配合 closest 处理嵌套结构

再复杂一点：按钮里可能有图标<i>或者<span>文本。用户精确点击的是图标的话，e.target就不是button，而是button内部的i。

你能依赖closest来解决这个结构问题：

todoList.addEventListener('click', (e) => { const deleteBtn = e.target.closest('.delete-btn'); if (!deleteBtn) return; const li = deleteBtn.closest('li'); if (li) li.remove(); });

这样无论用户点的是按钮文字、按钮图标，还是其他内部元素，都能正确找到带有.delete-btn类的按钮。用这一套，你可以应对绝大多数嵌套结构。

4.4><ul id="list"> <li>function delegate(container, selector, actionToHandler) { container.addEventListener('click', (e) => { const trigger = e.target.closest(selector); if (!trigger) return; const action = trigger.dataset.action; const handler = actionToHandler[action]; if (handler) { handler.call(trigger, e); } }); } const list = document.getElementById('list'); delegate(list, 'button[data-action]', { done() { const li = this.closest('li'); li.classList.toggle('completed'); }, edit() { const li = this.closest('li'); // 进入编辑态 enterEditMode(li); }, delete() { const li = this.closest('li'); li.remove(); }, });

这样写的好处是：

新功能加一个><div id="app"> <input type="text" id="taskInput" placeholder="输入任务内容" /> <button id="addBtn">添加</button> <ul id="taskList"></ul> </div>
这里我不写任何内联onclick，所有事件将来都交给 JS。
需要声明一个数据模型，用来管理任务：
```
const tasks = [ { id: 1, text: '学习事件冒泡', done: false }, { id: 2, text: '练习事件委托', done: false }, ];
```
为什么用数据模型？因为 DOM 只是视图，数据才是状态。如果你想做编辑、删除、筛选，直接操作数据再重新渲染，比一个个去操作 DOM 更干净。
5.2 用事件委托统一处理所有操作按钮
在taskList上只挂一个点击监听器，处理所有按钮行为：
```
const taskList = document.getElementById('taskList'); taskList.addEventListener('click', (e) => { const actionBtn = e.target.closest('button[data-action]'); if (!actionBtn) return; const li = actionBtn.closest('li[data-id]'); const taskId = Number(li.dataset.id); switch (actionBtn.dataset.action) { case 'toggle': toggleTask(taskId); break; case 'edit': enterEditMode(li); break; case 'delete': deleteTask(taskId); break; } });
```
这段代码的关键点：
- 用closest把"点中按钮内部图标"的情况收敛到按钮本身。
- 用li[data-id]拿任务的>function enterEditMode(li) { const textSpan = li.querySelector('.task-text'); const currentText = textSpan.textContent; li.classList.add('editing'); li.innerHTML = ` <input class="edit-input" value="${currentText}" /> <button>function saveTask(li) { const input = li.querySelector('.edit-input'); const newText = input.value.trim(); if (!newText) return; const taskId = Number(li.dataset.id); const task = tasks.find(t => t.id === taskId); if (task) { task.text = newText; } renderTaskList(); }
  回车保存的实现，可以在taskList上再加一个keydown委托监听：
```
taskList.addEventListener('keydown', (e) => { if (e.key === 'Enter' && e.target.classList.contains('edit-input')) { const li = e.target.closest('li'); saveTask(li); } });
```
  这个场景里，keydown也有冒泡，所以委托同样适用。
  5.4 渲染函数与新增任务的完整流程
  渲染函数负责把tasks数组变成列表 DOM。这里我用map拼字符串，用join合并，避免循环里频繁操作 DOM：
```
function renderTaskList() { const html = tasks.map(task => ` <li>function escapeHtml(text) { const div = document.createElement('div'); div.textContent = text; return div.innerHTML; }
```
  新增任务：
```
const input = document.getElementById('taskInput'); const addBtn = document.getElementById('addBtn'); addBtn.addEventListener('click', () => { const text = input.value.trim(); if (!text) return; tasks.push({ id: Date.now(), text, done: false, }); input.value = ''; renderTaskList(); });
```
  新增后不需要重新绑定任何按钮事件，因为所有按钮的点击最终都会冒泡到taskList的委托监听器上。
  5.5 最终验证与常见问题排查
  写完后，验证清单应该包含这些点：
  - 点击"完成"可以切换完成状态，文字不会闪退。
  - 点击"编辑"，列表变成输入框，数据在输入框中回填。
  - 在输入框按回车，内容保存，列表重新渲染。
  - 点击"取消"，恢复原样，不修改数据。
  - 新增任务后，新出现的按钮能用"编辑""删除"正常操作。
  如果发现点击"编辑"后按钮没有反应，排查看是不是新生成的按钮没有>const str = 'hello world'; str.includes('world'); // true str.indexOf('world') !== -1; // 老写法，配合 ES5 环境
  需要注意的是includes区分大小写。如果你做搜索筛选又不希望区分，可以先toLowerCase()再判断。
  6.2 js 判断数组是否有重复数据
  列表页经常有"去重"需求。最简单的判断方式：
```
function hasDuplicate(array) { return new Set(array).size !== array.length; }
```
  如果数组里是对象，需要根据某个字段去重：
```
const hasDuplicateById = (arr, key = 'id') => new Set(arr.map(item => item[key])).size !== arr.length;
```
  这个方法在数据量不大时性能足够，不需要额外引入库。
  6.3 iframe 如何关闭自身并刷新父页面
  这个场景涉及"跨窗口 DOM 操作"。假设你在一个 iframe 弹窗里，操作完成后要关闭弹窗并刷新父页面：
```
// 在 iframe 内部 window.parent.document.body.removeChild(window.frameElement); window.parent.location.reload();
```
  这里有一个大前提：父页面和 iframe 必须同源。如果跨域，window.parent.document会直接抛异常，这就是"contentwindow 无法找到 document"类问题出现的核心原因。同源策略是浏览器安全基座，除非业务场景允许你通过postMessage等方案与父页面通信，否则别想着强行绕过。
  6.4 动态导入脚本后 JS 访问不了如何排查
  根据热搜里的"将云路径改为本地路径后 js 访问不了"，这个场景一般是资源路径变化导致的。我建议按三步排查：
  1. 打开浏览器控制台 Network 面板，看 JS 文件请求是否 404。
  2. 如果是 404，检查路径是全相对路径还是绝对路径。改为本地路径后，前端页面的部署前缀可能变了。
  3. 如果请求成功但功能失败，看看是不是加载顺序问题。比如 JS 文件在 DOM 还未解析完成时就执行了，document.getElementById拿到了 null。
  排查手段本身，比最后的修复更值得记住。
  6.5 关于 DOM 型 XSS 的安全提示
  热搜里有"DOM 型 XSS"，必须提醒一点：DOM 操作最大的安全风险，就是把不可信内容用 innerHTML 直接写入页面。
  举一个典型场景：URL 参数?q=<img src=x onerror=alert(1)>被 JS 读取后，直接放进页面展示，就可能触发脚本。治理方法就是我前面说的：优先textContent，或者对内容做转义。
  事件绑定也一样，尽量避免动态拼接"字符串 HTML 里的内联事件"，因为它会让 XSS 防护变得雪上加霜。事件委托本身不会消除 XSS，但它会减少你"把事件写在 HTML 字符串里"的机会，从而缩小攻击面。
  写到这里，前端里关于 DOM 操作和 JS 事件的核心知识点，基本都过了一遍。从我自己的经验看，理解了冒泡的传播路径，理解了target和currentTarget的区别，理解了委托解决动态列表的思路，大部分页面交互问题你都能自己摸到根因，而不是靠一遍遍刷新碰运气。
  最后留个我一直在用的习惯：写任何事件相关代码前，先问自己三个问题——这个事件会在哪些元素上触发？它冒泡到哪一层才有意义？动态元素出现后，我的监听器还在不在？想清楚这三点，再动手写代码，基本不会给自己挖坑。

企业官网建设流程全解析

1. 先搞懂 DOM：从"找元素"到"改页面"的完整套路

1.1 获取元素的几种姿势，谁快谁慢

1.2 改内容、改样式、改属性的常用手段

1.3 为什么我建议你少用 innerHTML 拼结构

2. 事件机制：绑定、执行顺序和那个总被忽略的事件对象

2.1 事件绑定的三种写法和一种推荐

2.2 事件对象里藏着"现场证据"

2.3 先冒泡还是先捕获，记住这张规律就行

3. 事件冒泡：有用但也会闯祸，关键是知道它什么时候停

3.1 冒泡是怎么一路传到 document 的

3.2 stopPropagation 与 stopImmediatePropagation 的区别

3.3 我踩过的冒泡坑：弹窗关闭、菜单联动、统计误报

坑一：弹窗刚打开就被关闭

坑二：行点击与列操作的冲突

坑三：统计埋点重复上报

3.4 真的需要每次都阻止吗

4. 事件委托：用最少的事件监听搞定动态列表

4.1 为什么每个按钮挂监听器不是好主意

4.2 委托的核心实现：target 判定

4.3 配合 closest 处理嵌套结构

5.2 用事件委托统一处理所有操作按钮

5.4 渲染函数与新增任务的完整流程

5.5 最终验证与常见问题排查

6.2 js 判断数组是否有重复数据

6.3 iframe 如何关闭自身并刷新父页面

6.4 动态导入脚本后 JS 访问不了如何排查

6.5 关于 DOM 型 XSS 的安全提示

热门文章

文章分类

标签云

需要专业的网站建设服务？

企业官网建设流程全解析

1. 先搞懂 DOM：从"找元素"到"改页面"的完整套路

1.1 获取元素的几种姿势，谁快谁慢

1.2 改内容、改样式、改属性的常用手段

1.3 为什么我建议你少用 innerHTML 拼结构

2. 事件机制：绑定、执行顺序和那个总被忽略的事件对象

2.1 事件绑定的三种写法和一种推荐

2.2 事件对象里藏着"现场证据"

2.3 先冒泡还是先捕获，记住这张规律就行

3. 事件冒泡：有用但也会闯祸，关键是知道它什么时候停

3.1 冒泡是怎么一路传到 document 的

3.2 stopPropagation 与 stopImmediatePropagation 的区别

3.3 我踩过的冒泡坑：弹窗关闭、菜单联动、统计误报

坑一：弹窗刚打开就被关闭

坑二：行点击与列操作的冲突

坑三：统计埋点重复上报

3.4 真的需要每次都阻止吗

4. 事件委托：用最少的事件监听搞定动态列表

4.1 为什么每个按钮挂监听器不是好主意

4.2 委托的核心实现：target 判定

4.3 配合 closest 处理嵌套结构

5.2 用事件委托统一处理所有操作按钮

5.4 渲染函数与新增任务的完整流程

5.5 最终验证与常见问题排查

6.2 js 判断数组是否有重复数据

6.3 iframe 如何关闭自身并刷新父页面

6.4 动态导入脚本后 JS 访问不了如何排查

6.5 关于 DOM 型 XSS 的安全提示

热门文章

文章分类

标签云

相关文章

NumPy随机数模块深度拆解：从Generator到多进程最佳实践

无密码PAM方案：特权访问管理的安全革新

Ollama本地部署大模型：从安装到前端API接入完整指南

需要专业的网站建设服务？