JavaScript事件处理依赖事件循环、任务队列和事件传播路径三者协同，注册监听器不立即执行，仅登记回调；触发需用户交互、dispatchEvent或浏览器状态变更；DOM未就绪时绑定无效，动态元素需委托或重新绑定。
JavaScript 事件处理机制不是“注册后立刻执行”，而是依赖**事件循环（Event Loop）+ 任务队列（Task Queue）+ 事件目标传播路径（捕获→目标→冒泡）**三者协同。理解错其中任一环，都会导致 addEventListener 不触发、event.preventDefault() 失效、或 stopPropagation() 看似没用。
事件监听注册后为什么没立刻执行？
因为监听只是“登记预约”，不等于“马上干活”。真实触发取决于：用户交互/脚本主动 dispatchEvent / 浏览器内部状态变更（如 load、DOMContentLoaded）。
-
addEventListener只是把回调函数存进元素的监听器列表，不执行也不检查 DOM 是否已就绪 - 如果在 DOM 元素创建前就绑定事件，会绑定失败（
addEventListener调用成功但无效果），常见于脚本放在<head>且没加defer或DOMContentLoaded包裹 - 动态插入的元素（如
innerHTML += '...'）需重新绑定事件，或改用事件委托——监听父容器，靠event.target判断真实点击对象
click 事件为什么有时触发两次？
多数情况不是代码写错，而是浏览器在移动端或某些输入设备上同时派发了 click 和 mousedown/touchend，再叠加监听器重复绑定。
- 检查是否在
for循环里反复调用addEventListener，却没用removeEventListener清理（尤其 React/Vue 组件重渲染时） - 移动端 Safari 对
click有约 300ms 延迟，部分 polyfill（如 FastClick）会额外触发一次，造成双触发 -
label元素包裹input时，点击label会先触发label的click，再触发input的click（冒泡所致），可用event.stopPropagation()阻断，但要小心影响可访问性
preventDefault 和 stopPropagation 容易混淆的边界
preventDefault() 只阻止浏览器默认行为（如表单提交、链接跳转、滚动），stopPropagation() 只阻止事件继续沿 DOM 树传递（捕获/冒泡阶段），两者互不替代。
立即学习“Java免费学习笔记（深入）”；
- 阻止表单提交只需
event.preventDefault()，不必也不该调用stopPropagation() - 实现“点击弹窗外部关闭”，应监听 document，判断
event.target是否在弹窗内，而不是靠stopPropagation拦住所有子元素事件——否则按钮点不了 - 在捕获阶段调用
stopPropagation()，事件连目标阶段都不会到达；而在冒泡阶段调用，只影响祖先节点，不影响同级或兄弟节点 -
once: true选项比手动removeEventListener更可靠，避免因作用域或引用丢失导致清理失败
真正难的不是记住 API，而是在嵌套组件、第三方库介入、跨框架通信时，准确判断当前事件处于哪个阶段、谁绑定了监听器、谁调用了阻止方法。调试时优先用 Chrome DevTools 的 Elements → Event Listeners 面板看实际绑定情况，比猜更直接。
