JavaScript事件处理依赖事件循环、任务队列和事件传播路径协同，监听器生效需满足DOM存在、类型匹配、传播未中断及Shadow DOM配置正确；click不触发而mousedown可触发因click是含阈值判断的复合事件；event.target与currentTarget通常不等，委托场景下前者为实际触发元素，后者为绑定元素；event对象在处理器返回后被回收，异步中须提前提取所需属性。
JavaScript 事件处理不是“注册后自动执行”的线性流程，而是依赖于**事件循环（Event Loop）+ 任务队列（Task Queue）+ 事件目标传播路径（捕获→目标→冒泡）** 三者协同的结果。理解错其中任一环，就容易遇到 addEventListener 不触发、event.preventDefault() 失效、或异步回调里拿不到最新 DOM 状态等问题。
事件监听器怎么才算真正“生效”
监听器是否执行，不只看是否调用 addEventListener，还要看：
- 绑定时目标元素是否已存在于 DOM 中（动态插入的节点需重新绑定，或用事件委托）
- 事件类型是否匹配（
click不会响应keydown，input和change触发时机也不同） - 是否被
stopPropagation()或stopImmediatePropagation()中断了传播链 - 是否在 Shadow DOM 内部，且未设置
{ composed: true }选项
为什么 click 事件有时不触发，但 mousedown 可以
常见于移动端或某些 CSS 干预场景：
-
click是复合事件，需经历mousedown→mouseup→ 时间/位移阈值判断，任意一环失败（如preventDefault在touchstart里被调用、或元素有pointer-events: none）都会导致它静默丢弃 -
mousedown是底层原生事件，只要鼠标按下即触发，不受点击判定逻辑影响 - 移动端还需注意：默认 300ms 延迟（可加
viewportmeta 或touch-action: manipulation优化）
event.target 和 event.currentTarget 总是相等吗
不相等是常态，尤其在事件委托中：
立即学习“Java免费学习笔记（深入）”；
-
event.target永远指向**实际触发事件的最深子元素**（比如你点的是按钮内的span，那它就是那个span） -
event.currentTarget指向**当前监听器所绑定的那个元素**（比如你在父div上绑了监听器，那它就是这个div） - 混淆二者会导致误删节点、错误更新状态——例如用
target.remove()本意是删自己，结果删了子图标
异步操作里读不到最新的 event 属性？
因为 event 对象在事件函数返回后会被**自动回收**（部分浏览器甚至重用其内存），在 setTimeout、Promise.then 或 fetch 回调中直接访问 event.target 可能报错或返回 null：
- 正确做法：在事件处理器内提前提取所需值，例如
const id = event.target.id，再传入异步逻辑 - 不要依赖
event的引用存活，它不是持久对象 - 若真需完整事件对象，可用
event.clone()（仅部分现代环境支持），更通用的做法是手动构造轻量副本：{ type: event.type, target: event.target, detail: event.detail }
事件机制的复杂性不在 API 多少，而在各环节隐式耦合——DOM 更新时机、微任务清空顺序、事件流阶段切换、甚至浏览器对合成事件的优化策略，都可能让一行看似无害的 addEventListener 表现出意外行为。
