JavaScript事件处理依赖事件流、对象生命周期和注册时机；需等DOM加载完成再监听，推荐DOMContentLoaded；addEventListener第三参数可设capture/once/passive；事件委托利用target和matches()处理动态元素；preventDefault()取消默认行为，stopPropagation()阻止冒泡。
JavaScript 事件处理不是“绑定后就自动生效”的线性流程，而是依赖于事件流（捕获 → 目标 → 冒泡）、事件对象生命周期、以及监听器注册时机的协作机制。不理解这个底层逻辑，容易出现监听失效、重复绑定、阻止失败等问题。
事件监听必须等 DOM 加载完成才能安全使用
在 同步执行时，若脚本位于 或 HTML 元素之前，document.getElementById('btn') 会返回 null，导致 addEventListener 报错或静默失败。
- 推荐用
DOMContentLoaded事件包裹初始化逻辑，而非依赖window.onload（后者等资源加载完，更慢） - 如果脚本放在
前，可省略等待——但这是靠 HTML 解析顺序“赌”出来的，不具可维护性 - 现代写法：
document.addEventListener('DOMContentLoaded', () => { document
.getElementById('submit').addEventListener('click', handleSubmit); });
addEventListener 的第三个参数决定事件流向和行为
第三个参数不只是布尔值 true/false，它实际接受一个 options 对象，影响事件是否在捕获阶段触发、是否只触发一次、是否阻止默认行为等。
-
{ capture: true }：监听器在捕获阶段执行（从document→body→ 目标元素），常用于全局拦截（如权限校验） -
{ once: true }：监听器执行一次后自动移除，避免手动调用removeEventListener，适合表单提交、初始化动画等一次性操作 -
{ passive: true }：告诉浏览器该监听器**不会调用preventDefault()**，提升滚动/触摸性能（Chrome 强制启用后，若仍调用preventDefault()会报黄色警告）
事件委托是解决动态元素和性能问题的核心手段
给每个列表项单独绑 click 监听器，不仅代码冗余，还无法响应后续通过 JS 插入的新节点。正确做法是监听父容器，在事件对象中判断真实目标。
- 利用
event.target（触发事件的最深元素）而非event.currentTarget（当前绑定监听器的元素） - 用
matches()安全判断目标是否符合选择器：document.getElementById('list').addEventListener('click', (e) => { if (e.target.matches('li.delete-btn')) { const item = e.target.closest('li'); item.remove(); } }); - 注意：不要在委托中对
e.target直接调用remove()或innerHTML = ''，可能误删父级结构
阻止事件传播和默认行为需明确区分场景
event.stopPropagation() 和 event.preventDefault() 经常被混用，但它们解决的是完全不同的问题：
-
preventDefault()：取消浏览器默认动作（如表单提交、链接跳转、右键菜单），不影响事件继续冒泡 -
stopPropagation()：中断事件流（不再向上冒泡），但默认行为照常发生 - 真正需要“既不跳转也不冒泡”时才两者都调，比如自定义下拉菜单点击遮罩层关闭时：
overlay.addEventListener('click', (e) => { e.preventDefault(); // 防止意外触发锚点或表单 e.stopPropagation(); // 防止事件冒泡到 body 导致其他关闭逻辑 dropdown.close(); });
事件对象的 currentTarget 和 target 差异、冒泡被中间 stopPropagation() 截断后上级监听器收不到事件、被动监听器里调 preventDefault() 被忽略——这些都不是边缘情况，而是日常开发中高频踩坑点。写监听器前，先想清楚：这个事件该在哪一层处理？是否允许它继续影响别的逻辑？是否要干预浏览器默认行为？
