JS逆向 -- js 事件 事件循环 和异步（一）

逆向有你

2026年11月5日 12:09
河南

去阅读

WEB 逆向基础知识系列

js 事件 · 事件循环 · 和异步

作者：f20171110 ｜ 来源：吾爱破解论坛 ｜ 2026-6-7
全文约 12 万字，篇幅较长，建议先收藏再分次阅读

本文目录

1一 事件的综述

2二 事件的完整生命周期

3三 事件的传播和处理

4四 事件的循环和异步

PART 01

一 、事件的综述

在web逆向  js逆向  前端逆向中，  js语言本身是必须掌握的内容，甚至对于js内部原理和实现的掌握程度，比对普通前端开发者的要求都要高些。 js本身并不难，难点在于 js和js引擎，比如V8，js和js引擎和宿主环境 比如Blink 之间交织在一起。当然，主要重点就是js和V8。  至于这一篇的内容，事件和事件循环，主要是js和宿主环境 Blink 的，但是期约是js原生的。所以这篇文章的第一  第二部分，可以作为浏览性了解，第三部分事件的传播和处理  第四部分循环和异步 可以适当的多了解一下.
事件循环这个时序性的问题，对于web逆向来说，需要了解，但不是重点。

但是，在现阶段，对于开发者来说，不管是哪方面的开发者，js和浏览器方面的知识掌握，都是多多益善。

一 事件的综述

二 事件的完整生命周期

三 事件的传播和处理

四 事件的循环和异步

这四部分已经能覆盖js事件的绝大部分内容了，而且广度和深度都足够。

一二三的完成时间，距离现在时间比较长了， 第四部分是最近完成的，讲解比较通俗易懂，可以重点了解。

首先需要了解几个术语：

宿主环境：将js引擎作为一个组件包含在内，并且为它提供运行所需的资源的外部系统。
就是说，宿主环境提供了所有的资源，比如网络 文件 渲染 各种功能接口等等，没有了宿主环境，     js引擎就是光杆司令，它就只能空转，做不了任何事情。

宿主对象：所有不是由 JS 语言本身定义的、而是由环境提供的对象/功能/api，都叫宿主对象。

比如 Fetch document  XMLHttpRequest    等等 由宿主环境提供的都叫宿主对象。

而js语言定义的对象，比如 Array, Object, Promise, Math, Map 等等，是js的原生内置对象。

我们常说的 事件循环  任务队列 都是由宿主环境提供并且管理的。

说 js能怎样怎样，实际上是  js语言的能力+宿主环境赋予的能力 。

1。  事件的核心定义：

JavaScript 中的事件是宿主环境提供的一套标准化的异步消息分发机制，是系统内发生的、可被代码侦测到的“发生”或“信号” 。

事件是一种能力，那么是不是所有的对象 所有的元素  所有的节点，都具备事件的能力呢？

并不是所有， 这里就要提到一切的源头  事件目标 EventTarget  。

EventTarget是一个接口  是一个对象 ，你要具备事件的能力，必须要实现这个接口。

记得红皮书里讲那个迭代器部分，说要想具备迭代功能，必须实现迭代协议。事件也类似，

EventTarget是宿主环境提供的一种能力 一种功能 一个对象，拥有了它 就拥有了事件的能力。

这里要注意的是，事件 是宿主环境 也就是浏览器提供的，并不是js语言本身所有，这点很重要。

那么，如何获得这种能力呢？

•继承源头 创建一个类 ， extends EventTarget ，直接获得原生的正宗事件能力。

•纯手工写

•引入其他事件库

•框架内置

以上所说，是如何获得事件的能力， 而在平常的开发中，绝大部分，都是通过原型链，直接继承了EventTarget ，并不需要特地去获得。

所以，在很多文章中，并没有提到EventTarget，因为单纯从js的角度来说，它处理的元素 节点 对象 等等  都已经通过原型链拥有了  或者通过一些框架内的自定义实现了或者封装了事件的能力。

2。  事件的来源

事件的来源，分两个层面，一个层面  是规范中定义的来源，灵一个层面  是浏览器具体实现的队列。

•规范定义 dom源 ui用户接口源 网络源 导航和历史源 渲染源 这是几个主要的事件来源。

•浏览器的具体实现 浏览器将不同的来源的事件，映射为自己的多个任务队列，并不是完全按照规范中定义的来源来划分宏任务队列的。至于优先级，浏览器有自己的优化和调度策略 比如用户交互高优先 防鸡鹅调度打捞低优先等等。 这些队列，一般来说是依据优先级的大小来划分。 输入事件队列   通常是最高优先级 处理用户的交互，保证用户打字 滚动  点击 没有延迟 计时器事件队列  普通优先级 settimeout  等，  有限的优先级，定时器中的回调函数都放在这里等待执行。（settimeout实际是一个浏览器提供的api函数，它是一个同步执行函数，但是做的是异步调度的工作） 普通事件队列   一般默认优先级 最常用的队列  处理逻辑的主战场  网络  文件  数据  等等 空闲队列   最低优先级 requestIdleCallback 事件循环完全空了   没事做的时候   来这里瞄一眼。

3。 事件和观察者模式

观察者模式是一种软件设计模式。它定义了一种一对多的依赖关系。

•“一” ： 指的是被观察者。当它的状态发生改变时，它会对外发送通知。

•“多” ： 指的是观察者。它们一直盯着“被观察者”，一旦收到通知，就会自动执行相应的操作。 而事件机制，是对观察者模式的一个实现。 我们写代码时

•DOM 节点（如 button） 就是 被观察者。

•我们写的回调函数（function() { ... }） 就是 观察者。

•addEventListener 就是整个观察者模式的核心api，它安排了一个或多个观察者去盯着被观察者。

•被观察者状态发生改变，触发通知。

4。  事件和DOM事件

可能还是有不少朋友对事件这个概念有疑惑。

事件 是归属于宿主环境的，请记住js语言中 并没有事件的概念。

事件是一个信号，是系统内发生的任何值得注意的事情。比如：键盘按下了、图片加载完了、网络断了、数据到了。。。。。。

DOM 事件只是这个庞大信号系统中的一部分，专门负责网页内容（文档）层面的交互。

之所以把DOM事件单独拿出来说，是因为它是我们在编写代码时，接触最多的一类事件。

...javascript

DOM 事件 是指发生在 HTML 文档元素（节点） 上的特定的交互瞬间。

核心特征： 它们必须依附于某个 DOM 节点（如 , , document）。

典型场景： 用户和网页 UI 的交互。

常见例子：

click (鼠标点击)

keydown (键盘按下)

submit (表单提交)

touchstart (手指触摸)

那么作为对比，除了DOM事件以外，还有什么非DOM事件呢？

...javascript

A. BOM (Browser Object Model) 事件 / Window 事件

这些事件发生在浏览器窗口层级，而不是具体的 HTML 标签上。

resize: 浏览器窗口大小被改变。

scroll: 页面滚动（虽然常绑定在 document，但本质是视图窗口的行为）。

hashchange: URL 的锚点（#后面部分）发生变化（单页应用路由的基础）。

storage: localStorage 或 sessionStorage 被修改时触发（用于跨标签页通信）。

online/offline: 网络连接状态断开或恢复。

B. 网络请求事件 (Network Events)

当 JS 发起异步请求时，请求的状态变化也是事件。

XMLHttpRequest (AJAX):

readystatechange: 请求状态改变。

progress: 下载进度。

load/error/timeout: 请求成功、失败或超时。

WebSocket:

open, message, close, error。

C. 媒体事件 (Media Events)

专门针对

play / pause: 播放/暂停。

ended: 播放结束。

volumechange: 音量改变。

waiting: 缓冲中。

D. 跨线程/跨窗口通信事件

Web Worker: message 事件（主线程和 Worker 线程互相发消息）。

iframe: message 事件（父页面和子页面通信，即 postMessage）。

E. 开发者自定义事件 (Custom Events)

这是最高级的用法。不由浏览器触发，而是由代码手动触发。

使用 new CustomEvent() 创建，使用 dispatchEvent() 发送。

用途： 用于组件间通信。可以手动派发一个事件，而不是依赖点击。

那么，DOM事件和非DOM事件，有什么区别吗？

DOM 事件：

因为 DOM 结构本身是一棵树（Tree）。 当你点击一个按钮时，你不仅仅是点击了这个按钮，你同时点击了包裹它的 div，点击了 body，点击了 html，甚至点击了整个浏览器窗口。

•特征： 事件会在 DOM 树上“旅行”。

•路径： 捕获阶段（从外向内） -> 目标阶段（到达节点） -> 冒泡阶段（从内向外）。

•结果： 你可以在父节点（比如 div）上监听到子节点（button）的事件。这就是事件委托的基础。

非 DOM 事件：

比如 XMLHttpRequest（网络请求）或 Worker（线程通信）。它们的对象没有“父节点”的概念，它们是内存中独立的 JS 对象。

•特征： 只有目标阶段。

•路径： 事件直接发送给该对象，触发完就结束了。它不会传给它的“上级”（因为它没有上级）。

•结果： 你不可能在 window 上通过冒泡监听到某个具体 ajax 请求的 load 事件（除非你自己手动去转发）。

除了上面所说的传播机制不同，还有一个极其重要的区别：与浏览器原生行为的绑定。

DOM 事件： 通常带有浏览器的默认行为。

•a 标签的 click 会导致跳转。

•form标签的 submit 会导致刷新页面。

•键盘的 keydown 会导致输入文字。

•因此： DOM 事件提供了 e.preventDefault() 来阻止这些行为

非 DOM 事件：  通常纯粹是信息通知。

•XHR 的 load 只是告诉你加载完了。

•因此： 非DOM事件通常没有（但有例外）所谓的“默认行为”可供阻止。你调用 e.preventDefault() 没有任何意义。

5。  事件和事件对象event

通常来说，一个事件，之所以能成为事件， 要具有三个特质：

•遵循观察者模式

•携带事件的现场数据

•可观测的发生或状态的改变 那么 携带事件的现场数据，这个就是要讲的event了。 很多文章说，事件发生 比如鼠标被点击  马上就有事件对象被创建， 这个说法其实并不准确。 严谨的描述 event 的创建时机：在事件被包装成任务放入红任务队列排队 然后被取出开始执行，执行的第一步 是进行命中测试，确定事件发生的目标，第二步，才是创建事件对象。 第三步 是路径计算，确定传播路径。 关于具体的流程，下面会详细讲。这部分作为综述，只是讲事件对象本身。 在js层面的事件对象被创建之前，所有的相关信息，只是作为一个内存中的 c++ 结构体存在。 那么  这里可以再给事件对象一个较为明确的定义： 事件对象是浏览器将底层存有事件信息的 C++ 结构包装成JS 对象，并在路径计算前完成创建，目的是为了让路径计算算法能读取其配置，并再气候的传播过程中充当一个携带现场数据及动态上下文的载体。 我们知道，以前的很长一段时间，前端的情况是  先有规范  再有实现 或者 先有实现  才有规范 或者虽有规范 但是实现不完全符合规范 ，总之是比较混乱，但是现在的情况已经好了很多，我们已经可以逐渐的信赖规范了。学习的时候  尽管实现上有些许的差别，但是可以用规范去加强理解。规范含义：在 ECMAScript 相关的规范中，[[ ]]形式的名字表示一种抽象的内部插槽，它们定义了对象在语义上的内部状态或行为。它们是规范用来描述对象如何工作的术语，不是 JS 层能直接访问的普通属性。实现层面：js引擎和浏览器会用各种方式来实现这些规范中定义的抽象的内部插槽。JS 提供的可访问接口：很多内部插槽会通过公开的属性或方法提供出来（例如event.type、event.target、event.bubbles等，不止事件对象，js的其他对象也是如此。），这些公开接口并不是“直接读写了内部插槽”，而是这些内部状态的一种通过api暴露出来的方式。 因为事件对象可以说是事件中最重要的部分，所以，很有必要重点来学习，下面 我们用比较大的篇幅来详细学习事件对象。 事件对象，从js的角度来讲，它确实是一个真正意义上的对象，我们平常从红皮书 或者权威指南上看到的js对象的定义，略有简化，请记住这个终极理解：js对象的本质 = 非原始值 + 属性记录集合 + 原型链继承 + 由内部槽/内部方法决定行为从这个角度来说， 事件对象完全符合js对象的本质定义。 读过js红皮书的朋友也许记得，在不少章节中 都有...这样的内部属性的写法，也就是上面所说的内部插槽。 我们首先介绍js事件对象的内部插槽： 核心状态插槽定义在 Event 接口中，所有事件对象共用。内部槽位类型描述[[type]]String 事件类型（如\"click\",\"load\"）。初始化时设定。[[target]]EventTarget? 初始派发目标。在dispatchEvent调用时被设定。[[relatedTarget]]EventTarget? 与事件相关的次要目标（主要用于MouseEvent和FocusEvent）。注意：它也参与重定位。[[currentTarget]]EventTarget? 当前正在执行监听器的对象。在传播过程中实时更新，派发结束后重置为 null。[[eventPhase]]Integer 当前阶段：0 (NONE), 1 (CAPTURING), 2 (AT\_TARGET), 3 (BUBBLING)。[[timeStamp]]DOMHighResTimeStamp 事件创建时间（相对于 Time Origin 的高精度时间戳）。[[isTrusted]]Booleantrue表示由 UA（浏览器）生成；false表示由脚本创建。[[path]]List 传播路径。由一系列结构体组成，每个结构体包含item(invocation target) 等信息。[[touch target list]] List （仅用于触摸逻辑）用于处理“隐式捕获”，即手指移出元素后仍将事件发送给初始目标。

path 是传播路径，关于它的结构和填充，我们后面会详细的学习。

标志位插槽

通常在实现中会被压缩为一个 Bit Field 以节省内存。

内部槽位 (Flag)	描述
[[stop propagation flag]]	设置后停止向后续节点传播（stopPropagation）。
[[stop immediate propagation flag]]	设置后停止传播且停止当前节点剩余监听器的执行。
[[canceled flag]]	设置后表示默认行为被阻止（preventDefault）。
[[in passive listener flag]]	标识当前是否处于 passive 监听器中（此时忽略 preventDefault）。
[[composed flag]]	标识事件是否可以穿越 Shadow DOM 边界传播。
[[initialized flag]]	标识事件对象是否已完成初始化（防止重复调用 initEvent）。
[[dispatch flag]]	标识事件是否正在派发中（防止重入/多次 dispatch）。
[[bubbles]]	标识事件是否支持冒泡。
[[cancelable]]	标识事件的默认行为是否可取消。

子类专用槽位

根据事件类型（C++ 类）的不同，按需存在的槽位。以下列举最核心的几类。

a.  CustomEvent 接口

内部槽位	描述
[[detail]]	存储开发者传入的自定义数据（payload）。

b. UIEvent 接口 (鼠标、键盘事件的基类)

内部槽位	描述
[[view]]	通常指向 WindowProxy（即 window 对象）。
[[detail]]	对于 UI 事件通常是数字（如点击次数），不同于 CustomEvent 的 detail。

c. MouseEvent 接口

内部槽位	描述
[[screenX]], [[screenY]]	屏幕绝对坐标。
[[clientX]], [[clientY]]	视口（viewport）相对坐标。
[[ctrlKey]], [[shiftKey]], [[altKey]], [[metaKey]]	修饰键状态（按下为 true）。
[[button]]	触发事件的按键（0：左，1：中，2：右）。
[[buttons]]	当前按下的按键（位掩码，例如 1=Left、2=Right、4=Middle、8=Back、16=Forward）。

d. KeyboardEvent 接口

内部槽位	描述
[[key]]	键值字符串（如 \"Enter\"）。
[[code]]	物理按键代码（如 \"KeyA\"）。
[[location]]	按键位置（如 DOM\_KEY\_LOCATION\_STANDARD）。
[[repeat]]	是否为长按自动重复。
[[isComposing]]	是否在输入法（IME）组合过程中。

结构化/底层实现槽位

内部槽位	描述
[[Prototype]]	指向 Event.prototype 或子类原型。
[[Extensible]]	对象是否可扩展。
[[NativePointer]] 或 [[EmbedderField]]	这是js包装对象中存储的指针，指向底层C++ 的 原始对象

最后还有内部槽位通过对象属性对外提供的可访问的部分，即公开接口，在后面的部分会详细学习。

上面是出于对知识的完整性考虑，列出的表格， 在实际学习中， 前端开发者，了解到事件对象的插槽/槽位的深度，就已经是极限了，再继续深入学习，就是对应的c++结构，毫无必要。

而没有列出的path路径字段和内部槽位对外提供的可访问接口，后面会专门学习。

我们继续回到事件对象的创建，有两种创建方式：

•原生事件的创建 比如鼠标点击  网络事件  等等，这类事件，是在宏任务被取出，执行第一步命中测试，取得具体目标，第二步创建事件对象时创建的， 一旦确定了目标元素，浏览器引擎（C++ 层，而不是 JS 引擎）就会实例化一个 Event 对象（例如 MouseEvent 或 PointerEvent）。这个对象是宿主对象，它被填充了所有相关的上下文信息：target（刚刚找到的元素）、currentTarget（最初为 null）、坐标、时间戳、bubbles 属性等。（这些信息，原本是存在于值钱的c++结构中。） 这个时候，浏览器会在 JS 环境上创建一个 JS wrapper。这个 wrapper 和底层的 C++ 对象互相关联（wrapper 内含对宿主对象的指针/引用，就是上面表格中的[[NativePointer]] 或 [[EmbedderField]]，而宿主对象则通常保存一个对该js包装对象的弱引用或记录，以便于重复利用该js对象）。 至此，js已经有了事件对象，虽然是‘包装对象’，但是依旧是真正意义上的js对象。

•js创建的事件对象 是在js代码中自己创建的，通常使用  new ，在最新的红宝书第5版里，依旧在使用createevent的方式，已经不建议使用了。在自己new事件对象时，需要知道自己使用哪种具体事件的构造函数，因为每种具体的构造函数所拥有的内部槽位不同，无法混用或通用。 另外，js创建的事件对象，是同步创建的，执行到new代码，对象事件就立即生成， 这和原生的事件对象的创建不同。 自己new的事件对象 是纯正的js对象， 原生事件对象  是包装对象， 但是  他们都是真正的js对象。 事件对象的创建详细过程将在后面的事件的生命周期部分介绍。

PART 02

二、 事件的完整生命周期

在第一部分中， 介绍了事件中的一些重要的知识点。

重要的是eventtarget和event。

请注意，不要把这两个概念搞混淆了。

EventTarget 是一切的源头，它让某个东西，具备了事件处理能力。任何能处理事件的东西，都必须是已经实现了（继承也好 自己写也好 使用第三方库也好 ）这个接口。

Event 是 一次事件的全部内容与状态的载体  它包含一次事件中的所有状态 （所有状态 所有关联到的对象 所有动态行为等等）

在这第二部分里，我们介绍事件的完整生命周期。

以一个物理点击事件为例，他的整个生命流程如下：

1.物理信号： 用户在硬件（例如鼠标或触摸屏）上按下。设备向操作系统 (OS) 发送一个硬件中断信号，并附带位置数据。

2.OS 路由： 操作系统（例如 Windows、macOS、Android）接收该信号，确定哪个应用程序处于活动状态（即浏览器），并将此低级输入（例如“鼠标按下，坐标 X:Y”）传递给浏览器的浏览器进程 (Browser Process)。

3.IPC 到渲染器： 浏览器进程负责浏览器的“外壳”（地址栏、选项卡），但它不知道选项卡内的内容。它通过进程间通信 (IPC) 将事件（例如 mousedown）和坐标发送到负责该选项卡的渲染器进程 (Renderer Process) 。

4.合成器线程接收： 在渲染器进程中，事件首先由合成器线程 (Compositor Thread) 接收。该线程独立于主线程（js运行的地方）运行，负责平滑地合成页面的各个层（例如，用于平滑滚动）。

5.合成器命中测试： 合成器线程执行一次“快速”命中测试。它检查事件坐标是否落在它标记为“非快速滚动区域”(Non-Fast Scrollable Region) 的地方。该区域是页面上附加了事件处理程序（如 touchstart 或 click 监听器）的区域 。

6.事件路由决策： 如果事件不在非快速滚动区域（例如，在可滚动的空白区域），合成器线程可以立即处理它（例如，开始滚动页面），而无需等待主线程 。 如果事件在非快速滚动区域，合成器线程必须将该事件转发到主线程 (Main Thread)，因为只有主线程才能运行 JavaScript 。 在合成器线程的决策逻辑中，存在一个关键的性能瓶颈：当合成器线程发现触点位于“非快速滚动区域”（即绑定了 touchstart/wheel 等事件）时，默认情况下，它必须挂起页面的滚动渲染，先向主线程发送事件信号，并同步等待 JS 回调函数的执行结果。 为什么要等？因为浏览器无法预知你的代码中是否会调用 e.preventDefault() 来阻止默认的滚动行为。这种“跨线程的同步等待”一旦遇上主线程繁忙，就是造成移动端页面滑动卡顿（Scroll Jank）的根本原因。 而 { passive: true } 的本质，是开发者向浏览器签署的一份“异步执行承诺书”。 通过这个标记，你告诉合成器线程：“请直接开始滚动渲染，不要等我。我承诺在回调函数中绝不调用 preventDefault()。” 一旦建立了这个协定，合成器线程就会立即处理滚动帧（保证丝滑流畅），同时将事件以非阻塞的方式发送给主线程去执行逻辑。此时，即便你违约在回调中强行调用了 preventDefault()，浏览器也会直接忽略该指令并在控制台抛出警告。

7.排队成为宏任务： 当事件（现在是 C++ 层面上的一个结构）到达主线程时，它不会立即执行。它被封装并放入红任务队列（也称为“任务队列”或“回调队列”）中，等待执行。此时，它已成为 JavaScript 事件循环模型的一部分。

8.事件循环出队与任务启动： JavaScript 事件循环机制持续监控着状态。当主线程的调用栈为空，且微任务队列也被清空（确保前一个循环彻底结束）时，事件循环才会从宏任务队列中取出那个排队已久的 mousedown 任务。 注意： 取出这个任务，标志着浏览器开始执行该任务内部包含的一系列逻辑

9.主线程命中测试（深度）： 任务执行的第一步是在主线程上进行“深度”命中测试。与合成器线程（只知道图层）不同，主线程拥有完整的 DOM 树、CSS 样式和布局信息。它使用这些数据（特别是“绘制记录”）来精确确定事件坐标下最顶层的 DOM 元素。这个元素将成为 event.target。

10.创建事件对象： 一旦确定了目标元素，浏览器引擎（C++ 层，而不是 JS 引擎）就会实例化一个 Event 对象（例如 MouseEvent 或 PointerEvent）。这个对象（一个“宿主对象”）被填充了所有相关的上下文信息：target（刚刚找到的元素）、currentTarget（最初为 null）、坐标、时间戳、bubbles 属性等。 注意   ：现在 浏览器引擎会让js引擎创建js层面的事件对象，就是把c++层的宿主对象包装成js层的事件对象。但是，浏览器出于优化的考虑，也许会采用懒加载的方式  在第11步完成后，按需让js引擎创建js事件对象。   不过从整个流程的合理性来说，可以认为此时 js事件对象也被创建。

11.确定传播路径： 浏览器根据 DOM 树结构计算事件的完整传播路径。这是一个包含从 window 开始，一直向下到 event.target 的所有祖先元素，然后再回到 window 的有序数组。

12.开始调度（捕获阶段）： 任务现在开始沿着计算出的路径“调度”事件对象。它从 window 开始，向下传播到目标，在每个节点上触发已注册为在捕获阶段运行（{capture: true}）的 JavaScript 监听器 。

13.目标阶段： 这是一个特殊的阶段。规范在实现上并没有一个独立的“目标阶段循环”，而是将其拆解到了另外两个阶段中。 在捕获遍历到达目标时，浏览器会将目标标记为 AT\_TARGET，并执行目标上所有 capture: true 的监听器。 在冒泡遍历开始时，浏览器再次访问目标，将其标记为 AT\_TARGET，并执行目标上所有 capture: false（非捕获）的监听器。 所以，实质上是捕获类监听器先执行，非捕获类监听器后执行。同类监听器内部，才按添加顺序执行。

14.冒泡阶段： 事件随后从 event.target 向上传播回 window，在路径上的每个祖先元素上触发标准的（冒泡阶段）JavaScript 监听器 。

15.任务完成： 一旦事件到达 window 并且所有处理程序都已运行（前提是没有调用 stopPropagation()），这个宏任务就完成了。

16.微任务检查点： 在事件循环查找下一个宏任务之前，它会立即执行并清空微任务队列中的所有任务（例如，在事件处理程序中调度的 Promise.then() 回调）。

17.渲染： 在微任务队列清空后，浏览器现在有机会执行渲染更新（重绘页面）。

18.循环： 事件循环现在返回宏任务队列，以查找下一个任务。

下面，我们将以这整个流程为线索，介绍几个重要的步骤

从结构的角度来讲  物理点击  浏览器c++层创建初始结构  包装成宏任务入队列   被取出执行  命中测试 确定目标元素  浏览器c++层将初始结构和目标组合一起 创建了一个新的c++结构 填充槽位    浏览器调用js引擎  让js创建js层的事件对象 （包装了c++层的结构）填充关键槽位（可能有懒加载）  建立和c++结构的关联。

在具体的浏览器实现中， 有时会将第11步计算传播路径提前， 先计算传播路径   再开始创建js的事件对象。主要目的是可以通过先计算传播路径，确定是否有针对具体目标的监听， 假如没有， 那就根本没必要创建js的事件对象了。

介绍一下内部插槽的填充：

在命中测试完成 确定了具体的目标元素， 这个时候浏览器会创建一个c++事件实例结构，包括了最初的那个结构 又包括了目标元素，还有和事件类型相对应的内部槽位， 这是因为浏览器会根据事件的不同 调用不同的构造函数  创建不同的c++事件实例。每种事件实例都有专属于自己的槽位， 同时还有通用槽位。

浏览器创建事件对应的c++事件实例，填充内部槽位，我们先介绍静态数据， 这些数据一旦填充，在整个生命周期就不会改变。以下以一个点击事件为例

•[[type]] 根据事件类型（如 \"click\"）硬编码  静态只读

•[[isTrusted]]  值被设为true（因为是浏览器原生触发，如果是脚本模拟自定义 则为假）静态只读

•[[timeStamp]]  读取当前的高精度时间  静态 (只读)

•[[target]]  指向命中测试找到的最深层的那个 DOM 节点。  半静态 (Shadow DOM 中表现不同)

•[[NativePointer]]  指向底层的 C++ 结构体地址。  静态 (内部引用)

•[[screenX/Y]]  读取操作系统传入的硬件光标坐标数据。  静态

•[[bubbles]] 根据事件类型查表确定（例如 \"click\" 默认为 true，而 \"focus\" 或 \"scroll\" 默认为 false）。 状态： 静态 (只读)

•[[cancelable]] 根据事件类型查表确定（指示该事件是否允许通过脚本取消默认行为）。 状态： 静态 (只读)

•[[defaultPrevented]] 初始化为 false。 仅当脚本调用 event.preventDefault() 且 [[cancelable]] 为真时，该值才会被修改为 true。 状态： 动态 (可变)

•[[propagationStopped]] 初始化为 false。 这是一个内部控制标志，当脚本调用 event.stopPropagation() 时被设为 true，用于通知事件分发器停止遍历后续路径。 状态： 动态 (内部标记/不可见)

•[[underlying\_platform\_event]] 保存对原始底层硬件输入结构的 C++ 指针引用 就是最开始的那个初始c++结构。这实现了“零拷贝”机制，仅在 JS 访问特定属性（如 pressure, tiltX）时才通过此指针去读取底层数据。 状态： 静态 (内部引用)

注意：此时，[[currentTarget]] 还是 null，[[eventPhase]] 是 NONE (0)。

这里插一段，写这篇文章，一是自己需要对知识的总结归纳 二是希望写出来 是种分享，大数据时代  我们除了获取，不能忘记提供，关于木有图片。。。是因为我没有图床。。。其实就是懒。关于木有代码实例。。。还是因为懒。我喜欢用文字来描述来表达，虽然可能很多地方表达能力跟不上自己的想法。。。我是尽力了。其实我是有整篇的写作意图和明确的串联线索，只是写的多了，有时候就忘记或者是跑偏了，反正就是能力跟不上，反正就一个特点：字多。 大家当成小说看吧，其实我以前是写网文的。

我们学习到现在，已经能青春地意识到：

1.“真身”在下层： C++ 层面的事件实例 才是真正意义上完整、权威的事件状态载体。它用有物理原始数据、DOM 传播的实时状态指针以及所有标准定义的内部槽位。

2.“外壳”在上层： 我们在代码中操作的 JS 事件对象，本质上只是js 引擎创建的一个 代理壳 (Proxy/Wrapper)。

3.核心连接： 这个壳内部并不直接存储大量数据，它最核心的东西是一个指向 C++ 结构的 内部指针 ([[NativePointer]])。

4.数据获取的方式： 当我们在 JS 中访问属性时，并不是简单的读取内存，而是根据属性的特性，触发了不同的底层机制：实时透传 ：对于动态变化的数据（如currentTarget,eventPhase），JS 对象通过Getter 访问器直接穿透到 C++ 结构中读取最新值。懒加载：对于昂贵的计算属性（如composedPath()或标准化的path），只有当 JS 第一次请求时，C++ 才会计算并将其转换为 JS 数组，然后挂载到 JS 对象上。缓存和优化：对于静态不可变数据（如type,timeStamp,isTrusted），js引擎可能会在第一次读取后将结果缓存在 JS 壳的“快照”中，以避免频繁跨越 C++/JS 边界带来的性能损耗。

5.可扩展性： 这个 JS 壳虽然是代理，但它也是一个标准的 JS 对象。因此，我们手动添加的自定义属性（如 e.myTag = \"test\"）是保存在 JS 壳 自己的堆内存中的，C++ 层对这些数据一无所知。

下面开始计算传播路径

•浏览器使用内部算法， 从 target 开始，沿着父节点一直向上找，直到 window。这个过程会填充非常重要的 path 插槽。

•现在我们开始详细的介绍path内部插槽的构成和用途 假如不包括  Shadow DOM，那么路径的计算和确定，将是非常简单的   沿着target一直向上找到window就可以了。但是正因为Shadow DOM的存在，让传播路径的计算成了一个微有难度的工作。 简单的描述一下概念，不算严谨，但可以当作了解。 一个dom树中， 一个元素被挂载了一个影子dom，那么 该元素被叫为 host， 然后，逻辑上看 以host为根， 有了两颗树， 一棵是刚挂载的影dom树  另一棵是host原本的子节点元素树。  而挂载的影dom树，并不是直接挂载  而是用一个root 挂在host上，root下面   才是影dom。  host原本的子元素树  叫光dom  。   看这部分内容的朋友，应该是对shadow dom已经有了解的， 以上简单介绍，只是为了后面方便使用影dom 光dom host root 等名词。 在第一部分，曾为了知识的完整性，列出了内部插槽的其他部分的列表。 这里这部分作为可跳过的选看部分，将详细的介绍path内容，这部分内容我个人认为在可跳过的内容中，算是重要的，所以打算用略大的篇幅来讲，不感兴趣的朋友依旧可以跳过这部分 。 path中 是一个结构列表，每一项都是一个结构，对应着事件传播路径中的一个元素 严谨的说 对应着一个具备事件能力 即实现了targetevent接口 的对象。通过此列表，就可以观察到  本次事件的完整传播路径。  而且 事件的传播路径  是一次性创建， 创建好以后， 不会再更改，存在于事件的整个生命周期。传播路径是固定的，但是监听的调用等等还是会动态变化，这里只是讲路径的确定， 监听和传播过程  后面部分会详细讲。 在最新的权威文档中，path中的每一项，都有7个字段，下面逐一介绍

1。 invocation target（调用目标）

•类型：一个 EventTarget 对象（通常是 Node / Element / Document / Window，也可以是其它实现了 EventTarget 的对象）。

•描述: 这是该路径项对应的实际 DOM 目标。通常来说，就是当前的节点。

2。  invocation-target-in-shadow-tree (调用目标是否在 Shadow Tree 中)

•类型: Boolean

•描述: 一个布尔值，标记 invocation target 是否位于 Shadow DOM 树内部。

•作用: 用于处理 Shadow DOM 边界的事件封装（Encapsulation）。此标志影响分派算法在决定重定位（retargeting）和阶段（capturing/at-target/bubbling）时的行为，以及是否需要将目标“影子化/重定向”给 shadow host 等逻辑。规范在处理路径和设置 eventPhase、currentTarget 时会检查此值。

3。 shadow-adjusted target (Shadow 修正目标)

•类型  要么是 null，要么是一个 潜在的事件目标（potential event target）。

•描述（最关键）： 这是“对监听器可见的那个目标（retargeted target）”  具体说，当事件从一个 shadow tree 向外传播（或在 shadow 边界处被观察）时，浏览器会把实际原始目标根据监听器位置做重定位，重定位后的对象就称为 shadow-adjusted target。 在事件分派过程中：如果path中的某个项的 shadow-adjusted target 非空，规范把该 struct 视为“AT\_TARGET”类型的位置（用于设置 eventPhase = AT\_TARGET），并用它来决定在该位置要以什么 target 值去调用监听器。

•举例：若真实事件发生在 shadow 内部的某个 div，当在 shadow host（外部）上触发监听器时，shadow-adjusted target 可能是 host（或 host 的某个可见代理），而不是内部真实 div，从而实现了 Shadow DOM 的封装（retargeting）

•再举例：当事件从影DOM 冒泡到光DOM 时，为了保持封装性，外部不应看到内部的真实节点。这个字段决定了在当前项所处的位置上，开发者调用 event.target 时应该返回哪个节点（通常是 host，即影子的宿主，而不是影dom内部真实的节点）。

•再再举例  算了，不举了

4。 relatedTarget (相关目标)

•类型 null 或 一个 潜在事件目标。

•描述  用于那些有“related target”语义的事件（例如 mouseover / mouseout、焦点事件中的 relatedTarget 等）来记录在该路径层次上与当前 invocation target 相关联的另一个目标（经过 retargeting 后可能是不同的对象）。 简单来说  就是类似于 shadow-adjusted target，但是专门用于修正 event.relatedTarget。 比如在 mouseover/mouseout 事件中，如果相关元素在 Shadow DOM 内部，这个字段确保外部只能看到 Shadow Host，而不是内部细节。

•注意：relatedTarget 的值也会受到 shadow tree 封装/重定位规则影响

5。 touch target list (触摸目标列表)

•类型 / 含义：一个“潜在事件目标”列表（sequence/list）List of Touch objects。主要用于触摸/多点触控相关的事件以记录与路径中该 struct 相关的所有触摸目标（比如 touchstart 的多个触点）。

•语义 / 用途：在分派触摸/Pointer 类型的事件时，规范需要知道该路径层上哪些具体触摸点是相关的，以便在给监听器报告事件时能确定哪些触点属于当前 currentTarget 的上下文。

•专门用于触摸事件（Touch Events）。当触摸点在 Shadow DOM 内部移动时，需要修正触摸点的 target 属性，以符合 Shadow DOM 的重定标（Retargeting）规则。

6。 root-of-closed-tree (是否为封闭树的根)

•类型 / 含义：布尔值。表示该 struct 表示的 invocation target（或其相关信息）是否处在一个 closed shadow tree 的根（即该 struct 表示的那一层涉及到一个 closed shadow root）。

•描述: 标记该路径项是否是一个模式为 closed 的 Shadow Root。

•如果为 true，则在使用 composedPath() 获取路径时，路径会在这个节点被截断，外部无法通过 API 获取到封闭 Shadow DOM 内部的节点。

•这个标志用于实现 closed shadow tree 的封装保护：当 root-of-closed-tree 为真时，规范在构建对外暴露的 invocation target 列表或在清理路径时会采取特殊处理（例如阻止 closed tree 内部节点出现在 composedPath() 的对外结果中，或在路径清理时决定是否插入清理 struct 等）。通俗说：它帮助浏览器决定“哪些内部节点必须对外屏蔽”。

7。  slot-in-closed-tree (是否为封闭树中的 Slot)

•类型 / 含义：布尔值。表示在路径构建时当前节点是不是“一个处在 closed shadow tree 中的 slot（slot-in-closed-tree）”的上下文标记。

•语义 / 作用：与插槽（）与被插入的 light DOM 元素相关的路径构建有关。规范在把路径 append 到 event.path 时把这个标志一并记录，以便 later 在决定 clearTargets、retargeting、以及是否把某些 struct 暴露到对外路径（或触发 activation behavior）时使用。简单说，它用于正确处理插槽 + closed shadow tree 的组合场景

•同样用于控制 composedPath()的暴露范围，确保封闭树的内部结构不泄露。 以上7个字段，是规范规定的path中的字段，属于内部使用的数据，在我们的js层，并不能直接使用。 新的一天，有点忘记进度了，上面讲了path的7个规范定义的字段。目的是为了下面讲传播路径的计算。前面好像也讲过， 如果是没有影dom，那么从命中具体目标以后，直接网上挨个找爸爸，挨个填path中的项。很简单。 但是因为有了影dom，路径的计算有点繁琐。 那么被插槽进影dom的光dom元素，发生的事件它的路径如何呢？ 如果composed为真，此被slotted的元素上发生事件，路径为  此光dom--影slot--影root--光host--Document 如果composed为假，路径依旧是 此光dom--影slot--影root--光host--Document 这是因为规范规定：composed:false只是一个必要条件，但不是充分条件；还要满足 “该 shadow root 是事件目标所在根” 这个前提，才会被拦截返回null（从而阻止继续向上到 host）。 如果事件目标的根不是该 shadow root（例如目标属于 light tree，其根是document），那么该 shadow root 不会返回null，而是返回 host —— 事件继续传播。 也就是说，被插槽进影dom的光dom元素， 依旧归属于光dom树，在它身上发生的可冒泡事件，在影dom它的slot位置开始，经历  此元素---slot---root 达到影dom边界，此时 规范定义了判断算法，必须要满足两个条件，才会被拦截，一 是composed为假  二是该发生事件的元素的根是影root， 这样才会被拦截。 被插槽进影dom的光dom元素，归属于光dom树， 它的根为document， 而不是影root，所以不满足拦截条件。 很多资料或者文章把composed为假的情况 绝对化，从规范上说  是不对的。 对于影dom内部的元素发生的事件，composed为假会拦截，因为他们同时符合根为影root的条件。 但是对于归属于外部光dom的被插槽元素来说，它的根为document，不符合条件， 所以不会拦截。 上面第4个  relatedTarget比较有意思，可以稍微了解一下 含义：对于mouseover/mouseout、focusin/focusout等“有关联目标”的事件，记录相关目标。 这个字段，并不是所有事件都具有，一般是有节点间转移的动作的事件才有。 假如有元素a和b，鼠标此时在a上，现在，把鼠标从a移到b，那么，对于a来说，在它身上发生了mouseout事件，鼠标离开， 创建这个事件对象的时候，path路径中，target当然是a，而relatedtarget表示关联目标，就是和target对应的一个目标，因为鼠标是移动到了b身上，所以relatedtarget就是b。 如果我们从b的角度来看，在b的身上发生了mouseover事件，鼠标到了b身上，那么这个事件对象创建，它的path路径的target是b， 和它关联的目标 relatedtarget则是a，因为鼠标从a过来的。 请注意，relatedtarget也遵守 影子DOM 的重定位规则。 从影dom外面看，如果relatedtarget指向的是 影DOM 内部的元素，它也会被替换为Host。 用处： 在调用监听器时提供上下文（比如判断鼠标是从哪里移进来的）。 作为事件触发的裁决依据：浏览器会对比重定位后的target和relatedtarget。如果在某一层级，两个变成了同一个对象（例如都变成了 host），浏览器会认为没有发生实质性的交互，从而阻止该事件在这一层的触发。 上面第3个shadow-adjusted target(Shadow 修正目标)shadow-adjusted target含义：对于当前项 来说的目标，请注意，这个target是path中的一个字段，要和在event事件对象的内部插槽中，还有一个静态的原始目标对象相区别  不要搞混。通俗的解释：在影dom中   path中的target始终是发起事件的那个真正目标。  而跨出影dom后   该target变为host，  以host代替影dom内真正的事件发起目标，以实现不让外人偷窥到影dom内部情况的效果。也就是说，如果不存在影dom，则该target 始终都是事件的实际发起元素。 而在影dom中的项目上，也是事件的实际发起元素，但是越过root，在host这一项上，该target变为host，并且一直保持到window项。 请注意 对于被插槽进影dom的光dom元素，因为它依旧归属光dom，所以在影内  影外  host上，它的该target值都为真正的光dom本身。 用处：在该项上的监听器中读取event.target时要显示的对象。 当该项表示的事件对象为被插槽进影dom中的时候，无论在何处  其值都为真正本体。 当事件源是影dom内部元素，该项位于影dom外时，显示host，位于影dom内时 显示真正事件发起目标， 位于host时，显示host。    经过前面的大段铺垫，现在开始学习传播路径构建 这次是真的真的了。 之所以执着于大段的讲path的字段和事件对象的内部插槽，主要是我个人认为，js层面的公开的api，只是对内部数据的整合和包装，只学习他们，无法真正准确的了解事件传播路径的算法和之后的事件传播及处理，以及这些内部数据和标志位之间的配合所带来的对于外部来说 比较不好理解的现象。 当然  限于能力，写的比较散乱，从开始到现在  一大半都算超纲注水，所以要赶快回归。  观看时跳过上面的这一大部分就好了。 事件传播路径的构建，是一个算法，它是以当前DOM结构为基础的，不需要JS参与的行为。完全依靠dom结构，加上影dom的边际规则，逐步构建出来一条物理路径。所以  直到最后路径构建完成，我们都看不到监听等js的一根毛。 就类似于 传说中的低耦合，甚至是解耦，没耦。 路径的构建，基本上是浏览器引擎的活，  至于以后监听什么的，和路径没关系， 不管你听不听  路就在那里。不管你走不走，路也就在那里。 以后，js的监听和动态的设置活动，属于逻辑上的， 而现在构建出来的路径，属于物理上的。只需要注意一点   当前节点的状态，有可能是由之前节点创建时的js层面参与决定的， 但是也仅此而已，路径的创建，js一直是靠边站的。反正，就是这么个意思吧。 其实吧 写到这里  有点沮丧。。。 也就是一个遍历算法，做了那么多的铺垫，早点直接说不就得了吗。然后我又想到前几天刷到的小片段：   入职以后前三个月每月工资2000，第四个月开始4000， 大智慧的朋友说  那你等到第四个月再去入职。 继续码字 这里就不得不引出两个比较重要的概念： 合成/组成树  扁平树（ Composed Tree   flat tree ） 虽然名字是两个 但都是指的同一个东西，组成树的意思主要突出它的来源并不单一，比如光dom 影dom slot 等，然后根据规则组成的一棵树。 扁平树的意思是从组成以后是一个整体的角度来讲的， flat表示消除了原本的影dom和光dom的隔阂，把正确的slot的内容投影拍扁进影dom槽中，表示是一棵单一的连续的树。注意   归属并没有改变。 扁平树并不是一棵完整的或者部分的真实存在的树，它是一种规范中抽象定义，在实现中，逻辑存在，在需要时，动态计算出来的一种逻辑树。 从名字 从存在形式 都已经说了，那么 它的内容是什么呢 扁平树是以整棵 DOM 树为基础，但在遇到宿主host时，会使用其 影dom结构来替代原本的内容，同时将光 DOM 中被选中的节点“投影”进 影DOM 的插槽中，最终形成的一棵树。 那么这里要特别注意，在物理上，并没有什么变化，host下依旧是一棵光dom 一棵影dom，  扁平树是一种抽象的逻辑树，按照规则  把它需要的东西  提取出来。物理上 原来怎么样  现在还是怎么样。 ---------为了说清这扁平树 我可费了老大劲，改了好多遍。 渲染树 渲染树是基于扁平树，使用css规则，生成的用于布局和绘制的树。 好像暂时用不到渲染树，先不详细说了，后面讲到渲染再说。 dom树  物理存储结构，只有原始的层级。 扁平树  抽象出来的 ， 打通了光dom和影dom的隔阂   有逻辑层次结构 。 渲染树  扁平树加css规则  有视觉呈现结构。 事件传播路径的构建算法，大约有百分之七八十的内容，都以零散的方式在前面介绍过了，还剩一个系统性的算法描述作为总结，但是有点犹豫，因为虽然算法很简单，但是牵扯到的字段和标志位比较繁琐，需要比较大的篇幅来讲述，而这部分内容  在前端开发中，百分之八九十的可能性是用不到的。但是在写组件写库写shadowdom以及排除一些bug的时候，却是神兵利器。所以打算放在第三部分事件的传播和处理部分再详细介绍。 现在我们来思考一下，就是真的只用脑子思考，在写这整篇文章的时候  有些知识点 ，甚至在有些地方多次反复的强调它所处的阶段 所在的位置等等，就是不断的试图在读者的脑中  构建出一个完整的事件模型，说到流程，你可以想到主要步骤， 说到光dom影dom 你可以想到一棵树。 一棵dom树，某个节点被挂上了新的树，于是  这个节点成了host，下面有了两棵树 一棵光dom 一棵影dom。 这里有个问题，就是以哪棵树为着眼点，不少朋友认为，光dom是正宗嫡系，当然要以光dom为着眼点，关注上面有没有被slot等等， 其实是不恰当的。 要以影dom为主，以影dom的角度来看， 影dom被挂上来，就是接管 代替了光dom，我就是老大 看我的。 你光dom想干点啥，必须投影到我这里，你现在就是我的备件仓库/展销厅， 我给你机会，你才能出现。 这是一种思考模型，从物理dom树 到扁平树的转变，虽然光dom始终是host的子树，是物理存在的，但是在思考时 使用扁平树的角度， 因为扁平树和渲染树对光dom是默认忽视的。 那么 我们再稍微延申一下， 假如光dom树  没有被slot， 然后  我在js层面手动派发事件，会出现什么情况？ 我在以前刚开始学习时，曾误以为，传播路径有两条  一条物理的 一条扁平的，后来才纠正过来，始终就是一条路，依靠算法来决定怎么走。 依旧是路径构建算法，算法规定，A node’s get the parent algorithm, given an event, returns the node’s assigned slot, if node is assigned; otherwise node’s parent.  就是没有被slot的节点找到的父亲是物理链路上的父亲。 也就是说 事件会传播到host 然后继续传播到document。 js可以对它像对其他元素一样 进行操作。包括监听 派发  允许slot等等等。  唯一的问题  就是因为它没有进扁平树 也就进不了渲染树，在视觉上是不在的。 看不到  所以除了设置slot加入扁平树的操作以外， 其他的操作 要慎重，避免各种bug的产生。 影子dom也挺有趣的，给事件传播路径上增添了很多色彩，影子哥和事件传播路径的构建有关的内容，好像也差不多了。如果后续其他部分里还牵扯到Shadow DOM的内容，到时候想起来再讲吧。 这第二部分马上写完了，最后总结升华一下 记得在第一部分，提到了观察者模式，我们再再再的把它具体到事件上来。 事件的发生，不管是因为什么原因，它的本质，就是 期待关注 。 我有事，我有事啊，我说我有事了，这是事件的发生，我不需要知道谁会处理它，也不知道什么时候会被处理。 三个阶段，捕获 目标 冒泡 提供了时间上的选择权 和处理的策略   捕获是拦截和预处理 目标是现场自己的处理   冒泡是兜底和总结。 传播路径，提供了空间和层次上的哨位  路径上不同的哨位，有着自己的不同的职责和环境，他们看待经过自己的事件，是用自己所在的哨位职责来观察的，同一个点击事件，在buttnn上看，是用户点按钮了， 在form上看， 是用户可能在提交表单， 在document上看，是用户还活着  没噶呢。   就是说 你可以选择  在具体哪个抽象层级上来处理这个业务洛基。 而三个阶段和传播路径的结合，就是对于事件处理的从时间到空间到层次上的结合，择优选择，比如事件委托该放在哪里？ 时间上，当然是选择到最后的冒泡了，空间和层次上  当然是选择越高越好了  大内总管那岗位厉害。而每个哨位  也有自己的小权力 比如这事归我管，不往上送了，比如这事只归我管 不给周围同事了。 最后  我们进入玄幻模式： 事件流为我们提供了时间空间层次三维立体的选择权。

PART 03

三、 事件的传播和处理

简介

我们将介绍事件的传播和处理， 这部分的内容，相关的介绍 文章  帖子 可谓是汗牛充栋栋栋栋栋。。。但是 基本上都是先讲三个阶段  然后扔出几个api 然后几段示例代码  然后总结一下  完事。  相信有很多朋友  看过以后  感觉是看了一些什么，但是仔细想想   又似乎是什么都没看，毫无获得感。其实这就是因为很多文章 都是知识的罗列，就像 教你说  哎 小明 你看  你按一下这个开关  灯就亮了  再按一下开关  灯就灭了。  但是  只有罗列  没有知识之间的桥梁  没有构建出一个合适的思考模式，只是浮于表面的认知。 你按一下开关  灯没亮 哎呀  咋回事嘞？ 或者按一下开关  灯没灭  或者你按一下开关 砰的一声 灯炸了  只能夸它炸的响 不知道它为什么炸 。我尽量不走寻常路，从其他的角度，我们一起来学习事件的传播和处理。风格依旧跟第一部分和第二部分一样， 没图没码 网文风格，但是对描述和表达的准确性  依旧值得信赖，我会力求表达准确 符合规范  贴合实现。

复习EventTarget

第一部分讲了事件的一些重要知识点，第二部分讲了事件的完整生命周期，并且用了大量篇幅介绍了传播路径的构建和shadow dom 以及事件对象。

这是第三部分

前面两部分是纯练内力，这部分有点内力外放的意思。现在我们一起修炼吧。

一切的源头是 eventtarget，前面已经多次提到，想具备事件能力，必须实现eventtarget接口。

eventtarget是一个接口  一种能力 一个对象。 从对象角度来说，  dom事件中的那些节点，基本上都是以原型链的形式默认继承了eventtarget这个对象。

在前面第一部分， 我们曾给出了一个js对象的新的定义：

js对象的本质 = 非原始值 + 属性记录集合 + 原型链继承 + 由内部槽/内部方法决定行为

eventtarget作为对象，那就必然可以用这个定义来解释。

一个实现了eventtarget接口的对象，具备了事件能力，那么将它用上面的定义来解释：

•非原始值：它当然是个对象引用。

•原型链继承：打开 F12，在控制台里敲入一行命令：console.dir(document.createElement('div'))  回车之后，会得到一个纯净的 div 对象。 顺着它的 [[Prototype]]（或者 \\_proto\\_）一层一层往上翻   从 HTMLDivElement 到 HTMLElement，再到 Element 和 Node   再然后，就看到我们的主角了  EventTarget。

•属性记录集合：当然可以随便添加属性。

•现在还剩下的就是最重要的了 ------ 由内部槽/内部方法决定行为

在 EventTarget 内部，有一个js层面看不到的内部槽位。 规范中它的名字叫 Event Listener List（事件监听器列表）。

正是因为有了这份列表，它才从普通的 JS 对象，进化成了一个拥有事件能力的对象。

因为它是对象内部的一个属性/槽位， 可以这样表示 eventlistenerlist

从名字就可以看出，它是一份列表，由每一条列表项组成。

下面我们介绍一下每份表项的构成，你就会明白了。

事件监听列表的组成

跟全文的第一部分和第二部分一样，依旧延续哨位这个比喻。

事件监听列表，每个表项 ，由7个字段构成。

1。. type

•类型：字符串 (String)

•含义：这个表项具体负责哪块业务？是 click 组的，还是 keydown 组的？

•作用：这是最基础的索引。比如当类型为click时，只有 type 为 \"click\" 的表项会被调出。

2。. callback

•类型：函数 或 对象 (EventListener Object)

•含义：具体干活的回调函数。

•细节：通常我们传的是一个 JS 函数。规范里讲的，也支持传一个对象，似乎很少使用。

3。. capture

•类型：布尔值 (Boolean)

•含义：这是最重要的身份标记之一。 true：属于捕获组。事件从 Window 往下传的时候，就要注意了。 false：属于冒泡组。事件从 Target 往上冒的时候，就要注意了。

•核心规则：它是“去重复算法”的三大要素之一。同一个函数，如果分别注册了捕获和冒泡，那是两条完全独立的表项。

4。. passive

•类型：布尔值 (Boolean)

•含义：这是一个关于性能的字段。 true：该表项签署承诺书，保证在执行过程中绝不调用 preventDefault()（不拦路）。 false：保留拦路的权力。

•有默认：浏览器为了保证移动端滚动的丝滑，对于 touchstart 或 wheel 这种高频事件，会在Window、Document 等顶层对象上默认帮你勾选为 true，以便合成器线程能直接渲染滚动帧。

5。. once

•类型：布尔值 (Boolean)

•含义：一次性用品。 true：干完这一票就走人。

•机制：当这个回调被执行之后，哨位会自动把这份表项从列表中物理删除。

6。. signal

•类型：AbortSignal 对象

•含义：这是 AbortController 带来的新机制。 机制：你把一个遥控器（Signal）交给哨位。以后你想离职，不用专门跑一趟（调用 removeEventListener），你只需要在外面按一下遥控器（调用 abort()），哨位里对应的列表项就会自动销毁。 细节：如果你递交申请的时候，手里的遥控器显示“已引爆”（aborted），是根本不会受理你的注册请求的。

7。. removed

•类型：布尔值 (Boolean)

•含义：这是唯一的内部专用字段，开发者不可见。 作用：解决同一事件中的并发问题。 场景：当在同一个事件派发中，在当前正在工作的哨位上，如果前一个表项中的回调，把后面的表项移除了，此字段起作用。 逻辑：为了不打乱正在进行的循环索引，哨位不会立刻移除表项，而是悄悄在这个字段打个勾（removed: true），类似于软删除。等轮到被打勾的表项的时候，直接跳过，既不执行也不报错。

看到这些字段，是不是感觉特别熟悉？ 注意  这些字段  现在是在eventtarget中的内部槽位中，仅限内部使用， 那么，它们是怎么被外面js层改变设置的呢？

eventtarget的对外窗口

前面反复的说  eventtarget是事件机制的源头，必须实现这个接口 才能具备事件的能力。dom事件中的节点，都是默认通过原型链继承了eventtarget对象。 那么，我们在js层面，如何使用呢？

eventtarget提供了三个api给我们，这也是它的核心功能，注册  销毁 触发。

前面讲过，一个事件  之所以能成为事件， 要具备三个特质：

一是遵循观察者模式，二是携带现场数据  三是可观察的变化。

那么eventtarget提供的这三个api，之所以是核心能力，就是因为用这3个api，实现了观察者模式。

addeventlistener注册 添加观察者

removeeventlistener退订 移除观察者

dispatchevent触发 发布者发布

这三个api，加上event，构成了大部分前端开发者的事件机制的知识体系，那么  假如再加上 事件监听列表   。。。。。。你就功力大涨，凝聚金丹进阶了。

1. addEventListener

给元素添加事件，经历过三个时期：

一，HTML 属性绑定 (Inline Event Handlers)

这是最早期的 web 开发形态，直到现在，依然可以在很多老旧系统或者为了图方便的 demo 中看到它的身影。

这种方式， 虽然看起来简单，直接把代码写在标签里，但它背后发生的事情其实非常不科学。

比如  ，浏览器并不是直接运行这段代码。 浏览器引擎在解析 HTML 时，会把onclick属性里的字符串console.log(id)提取出来，然后动态创建一个函数。它通常使用了一个在现代 JS 中已经被强烈建议不再使用的 with 语法，强行扩展了作用域链。

浏览器生成的代码逻辑大致如下（伪代码）：

...javascript

function(event) {

with(document) {

with(this.form) { // ...

with(this) {

// 自己的代码被包裹在这里了

console.log(id);

}

}

}

}

这就是为什么这种方式，可以直接在html里使用event  ， id，document的console的原因。

这种方式是强耦合的典型，HTML 和 JS 逻辑死死纠缠在一起。而且，因为 with 语法的存在，变量查找路径变得极其复杂，极易引发性能问题和意想不到的 Bug。而且，这种内联脚本，经常会因为安全问题，被禁止运行。

二，DOM0 级事件处理 (DOM0 Event Handlers)

随着 JS 的地位提升，还想再提升 再提升  于是就希望能把逻辑从 HTML 中剥离出来。于是出现了 DOM0 级绑定。

...javascript

btn.onclick = function() {

console.log('你好了吧');

}

这种方式的本质，是对 DOM 对象上的一个属性进行赋值。

（重要）这两种方式的总结

现在我们来撸一下思路，事件被包装成任务，放入宏任务队列， 然后被取出执行，精确命中，创建事件对象，构建传播路径， 此时，就进入调度阶段。  此时  我们把目光放在传播路上的某一个节点/元素/eventtarget 上面，它的内部 有一个自它出生就有的一个事件监听列表，该列表初始为空， 而此节点，作为一个对象，一个元素，它本身是有自己的属性的，比如 src属性  onclick属性，等等。。。以onclick为例，它是节点对象元素标签的一个属性，它在事件监听列表中，拥有一个单独的席位，初始为空，并不实际占有位置。 按照注册顺序来排列监听列表。 比如首先 add了几个回调， 然后又以btn.onclick=fn的方式注册了onclick， 那么 onclick是排在最后的。  又比如，首先以html的写法onclick=\"console.log(id)\"的方式内联注册了onclick，那么在html解析时，该属性就被注册了，它就排列在事件监听列表的首位。

还有一个重要的地方，就是 onclick是作为节点的一个固有属性存在的，它的值只能有一个，多次赋值会被覆盖。

而后面将要讲的add的方式添加的，是附加的方式，可以添加多个。

最后再次总结一下：

对于 HTML 属性绑定和 DOM0 (btn.onclick) 绑定，它们在浏览器内部，其实共享同一个内部槽位： 它们会在事件监听列表中寻找（或者创建）一个带有特殊标记的表项。

•唯一性： 这个表项，对于同一种事件类型（比如点击），只能有一个。

•独占性： 无论你赋值多少次 btn.onclick = fn，浏览器做的不是“添加”，而是“原地换人”。它找到那个表项，把里面的 callback 字段擦掉，填入新的函数。这就是为什么 onclick 永远只能绑定一个处理函数，因为它霸占了这个唯一的列表项。

•生命周期： 如果你把 btn.onclick 设为 null，浏览器就会把这个 表项从列表中物理移除。

三，DOM2级事件监听addEventListener

随着 Web 应用越来越复杂，组件化开发成为主流，如果一个按钮既要发送统计数据，又要执行业务逻辑，还要触发 UI 动画，用 onclick 就会互相打架。于是，addEventListener 诞生了。

它的逻辑和以前完全不同。dom0是独占和唯一，那么 addEventListener 就是 “追加”。

...javascript

btn.addEventListener('click', fn1);

btn.addEventListener('click', fn2);

调用这个 API 时，浏览器它只会做一个动作：Append（追加）。 它创建一个新的表项，填好 type、callback，然后直接把它挂在列表的末尾。

它的优势：

1.无限叠加：你可以添加无数个监听器，它们和平共处。当事件触发时，浏览器会按照列表中的顺序（也就是注册的顺序），依次执行它们。

2.精细化控制：这是 DOM0 做不到的。 你可以控制是在捕获阶段触发还是冒泡阶段触发（通过 capture 选项）。 你可以控制它是否只执行一次（once: true）。 你可以承诺不阻止默认行为以提升滚动性能（passive: true）。 你可以随时用信号终止它（signal）。 那么，是不是真的可以无限叠加任何监听呢？并不是。 为了防止你因为代码逻辑混乱或者一时糊涂手抖而重复注册同一个函数，浏览器在追加之前，会有一个严格的查重机制 这道机制只认三个字段：

3.type（事件类型）

4.callback（回调函数引用）

5.capture（捕获状态） 请注意，只有这三个！ passive、once、signal 这些后来加入的参数，不参与去重判断。 就是说  如果你先注册了一个 { passive: true } 的点击事件，然后又注册了一个一模一样的函数，但是参数变成了 { passive: false }。 浏览器会对照字段：

Type 一样吗？一样 (click)。
Callback 一样吗？一样 (同一个函数引用)。
Capture 一样吗？一样 (默认都是 false)。

结果判定为重复人员！ 浏览器会直接忽略第二次的注册请求。列表里依然只有第一次的那条记录。尤其要注意capture这个字段，前两个字段一样，第三个，真和假 可以同时存在于监听列表中。

还有一点

addEventListener的第二个参数，也可以是一个对象，这个对象里面，必须实现一个handleEvent方法：

...javascript

const myObj = {

message: 'Hello World',

handleEvent: function(event) {

// 这里的 this，自动指向 myObj 对象本身

console.log(this.message);

console.log(event.type);

}

};

// 传入的是对象，而不是函数

btn.addEventListener('click', myObj);

这种方式一是有利封装 二是不用绑定this，三是移除方便 。但这种传对象的方式我们平时使用不多。

2. removeEventListener

有注册就有注销，addeventlistener是往事件监听列表里添加观察者，removeeventlistener 就是用来把观察者从列表中请出去的。 它的工作很简单，就是使用上面提到的那三个字段去列表里找人：

1.type

2.callback

3.capture 符合条件，就请出去了。

这也是红宝书上说的，必须符合三个条件的原因，因为添加的时候，用这三个条件判断是否是重复添加， 所以用这三个字段，可以唯一表示事件监听列表里的某一项，那么在移除时，依旧是使用这三个字段来寻找。

那么问题来了，记得不要使用箭头函数当回调。因为，回调函数，如果是匿名的，你在注册时，它是一个对象，有一个内存地址， 你在移除时，写的回调，虽然和注册时是一样的内容，但是它是另一个不同的对象，有另一个不同的内存地址， 移除时并不是比对内容，而是比对的内存地址。地址不同，当然移除不掉的。

...javascript

// 注册

btn.addEventListener('click', () => { console.log('猜猜我是谁') });

// 试图移除

btn.removeEventListener('click', () => { console.log('猜猜我是谁') });

还有一点  要特别注意capture 是必须要匹配的！

在浏览器的眼中，捕获阶段的监听器 和 冒泡阶段的监听器，是完全不同的，

...javascript

// 注册了一个捕获阶段的监听器

btn.addEventListener('click', handler, { capture: true });

// 试图移除一个冒泡阶段的监听器

btn.removeEventListener('click', handler, { capture: false }); // 失败嘞

虽然函数一样，类型一样，但一个是捕获阶段，一个是非捕获阶段，浏览器认为它们不是同一个列表项。 要想移除上面那个，就必须显式地写上 { capture: true }。

关于事件监听列表种的第7个字段removed

还记得我们在前面介绍监听列表的7个字段时，提到的那个 内部专用字段 removed 吗？ 我们在这里略为介绍一下。

想象一下，假如有一个按钮，练功走火入魔了，居然注册了 10 个点击事件监听器。 当点击发生时，浏览器开始在一个 for 循环 中遍历这 10 个监听器，依次执行。 假设执行到第 3 个监听器时，它的代码里调用了 removeEventListener，把第 4 个监听器给删了。如果浏览器直接把第 4 个项从数组里 物理删除，数组长度这就变短了，后面的元素下标全部前移。 原来的第 5 个变成了第 4 个。 而循环的索引 i 此时加到了 4。   后果就是 ，原来的第 4 个被删了，原来的第 5 个被跳过了。

为了避免这种遍历中修改所带来的索引bug，浏览器采用了 “软删除” 策略。

当调用 removeEventListener 时：

1.浏览器找到了对应的表项。

2.它不会立即把它从内存里删除。

3.它只是悄悄地把该表项的 removed 标志位设为 true。

在事件派发的循环中： 当轮到这个表项时，浏览器会先看一眼：“哎呀 removed 是 true？”   然后  直接跳过不执行，继续下一个。

等到这一轮事件循环彻底结束，或者在未来的某个空闲时刻，浏览器才会真正地回收这些“被标记的僵尸”，释放内存。 这就是为什么说 removeEventListener 是一个逻辑上的删除，而不是物理上的立即消灭。这就是这个removed字段的用途。

那么  问题又来了， 哎呀，这么麻烦丫，删点东西 又要这 又要那的，有没有更先进的办法呢？ 这就是事件监听列表中  第6个字段signal 出现的意义了。

在前面，我们特别的讲了，不要传匿名函数进去当回调，因为想移除的时候，会匹配不到。那么现在有了signal的加持，匿名函数也能支楞几下了。

...javascript

const controller = new AbortController();

// 注册时，把销毁信号传进去

btn.addEventListener('click', () => { console.log('你们逮不到我'); }, { signal: controller.signal });

// 想移除时，不需要知道函数是谁，直接按下引爆器---砰

controller.abort();

AbortController 是一个构造函数， 使用new AbortController() 实例化出一个控制器对象。

这个对象很简单，包含一个signal属性，一个abort方法

这个对象是宿主环境提供的

AbortController 的出现，就是为了提供一种通用的取消机制。

使用 removeEventListener 时，必须使用回调函数的引用。但是用 AbortController，不需要管回调函数是谁，只需要控制那个信号。

而且，可以一对多的控制，可以把同一个 signal 传给 10 个不同的 addEventListener，甚至传给几个 fetch 请求。当调用一次 controller.abort() 时，这 10 个事件监听器和那几个网络请求，会同时停止。一键清理，厉害大了。

3. dispatchevent

dispatchevent的执行，和内部的派发过程是一样的，可以认为，它是内部的派发算法给js层面提供的一个接口。具体的执行，在后面会有超大的篇幅来讲。

在这部分 我们主要讲一下自定义event

在前面的第一部分讲解event的时候，我们说  自己创建event对象，需要使用对应的构造函数，因为内部槽位有通用的 也有专用的。

new Event()

const evt = new Event('boom');

这种，就纯粹是个消息通知，听个响而已，派发它，只能用于通知，看到通知，就回调。

new CustomEvent()

DOM 规范专门提供了：CustomEvent。 它是我们日常开发中最常用的方式。

...javascript

const payload = {

username: '阿祖',

action: '收手吧 外面全是成龙'

};

// 第二个参数是配置对象

const evt = new CustomEvent('police-arrive', {

detail: payload

});

document.addEventListener('police-arrive', (e) => {

console.log(e.detail.username); // 阿祖

});

detail里面可以放任意类型的内容，使用非常方便。

使用 EventInit  可配置对象

对于上面这两种 event和customevent，还可以使用配置对象对他们进行配置。

实际上，这种配置，是对于event内部插槽的修改，对于这两种属于基类的，只能配置

三个功能：  是否可冒泡bubbles   是否可取消cancelable   是否可跨影dom边界composed，他们初始默认都为假。

对于一般使用，以customevent加detail加三个配置项 居多。

继承 Event 类

使用 class myEvent extends Event {}

这种深度定制，可定制事件类型 可定制高内聚的逻辑。

但是写起来比较麻烦。

可能有新手朋友会有疑问  我new event 然后自己添加，和我使用extends event继承，有什么区别吗？ 不都是要自己添加吗？  对于特别简单的，当然可以new以后添加，但是稍微复杂点的，尽量使用继承，new加上添加，会有不可预知的安全问题，强类型，封装性  ，安全性，可固化配置。。这些优势，足够驱使选择继承的方式了吧。

那么 我想精确的造一个点击事件怎么办

这就需要拥有特定专用内部槽位的子类出场了，点击事件是

MouseEvent

...javascript

const perfectClick = new MouseEvent('click', {

//下面的配置项目，就相当于修改event对象中的内部槽位

//每种子类，拥有通用内部插槽， 也必须有自己的专用内部槽

// 1. 基础配置 通用槽（继承自 EventInit）

bubbles: true,       // 必须为 true，否则父元素收不到冒泡

cancelable: true,    // 必须为 true，否则无法 preventDefault

composed: true,      // 穿透 Shadow DOM

// 2. 视觉上下文（继承自 UIEventInit）

view: window,        // 绑定当前窗口

// 3. 物理信息 这是鼠标事件的专用内部槽（MouseEventInit 特有）

clientX: 100,        // 鼠标相对于视口的水平坐标

clientY: 200,        // 鼠标相对于视口的垂直坐标

screenX: 100,        // 相对于屏幕的坐标

screenY: 200,

// 4. 按键详情 依旧是鼠标事件专用内部槽

button: 0,           // 0: 左键, 1: 中键, 2: 右键

buttons: 1,          // 当前按下的键的位掩码 (1 代表左键被按下)

// 5. 修饰键 配合键盘使用

ctrlKey: false,

altKey: false,

shiftKey: true,      // 假装用户同时按住了 Shift

metaKey: false,

// 6. 关联目标   这个内部槽位的详细说明  请参见本文的第一部分

relatedTarget: null  // mouseover/out 时有用

});

// 开车喽~~~

btn.dispatchEvent(perfectClick);

这部分内容，是event的创建， 因为dispatchevent派发 就必须讲到这部分。所以就放在这里了。

关于dispatchevent，下面专门详细的介绍。

事件的派发和处理

梳理线索  整理思路

现在，我们来快速梳理一下我们已经学过并掌握的知识脉络

第1，事件对象

...javascript

事件的三个特质 ，1是遵循观察者模式，这样才能发布-订阅-移除-处理 ，2是携带事件的现场数据，这就是event对象，事件的传播以它为主， 3是可观测的发生活改变，这个就不用说了。

事件对象event的创建是在什么时候？回忆一下第二部分的流程，以点击事件为例，物理信号-操作系统路由-进程间通信给到渲染器-合成线程接收进行预先独立合成-合成器进行一次大致的命中测试-事件路由决策-被封装成任务进入宏任务队列-取出开始执行-深度命中测试找出目标-创建js层event-构建事件传播路径

（实现上以v8/blink为例）

通常 在创建js层事件对象 构建事件传播路径  甚至包括调度部分  明显的界限不好区分，因为有浏览器的实现差别和优化策略的不同，但是并不影响我们理解。

event是贯穿全程的唯一信物。它是一个底层  C++ 对象，内部包含了大量的内部插槽，JS 层的 event 对象只是它的一个浅层包装壳/代理。

身份信息

•[[type]]：事件类型（如 \"click\", \"mousedown\"）。

•[[isTrusted]]：true（浏览器生成）或 false（用户脚本生成）。

•[[timeStamp]]：高精度时间戳（事件创建那一刻的时间）。

•[[target]]：原始目标。即精确的命中测试（Hit Test）找到的最精确的 DOM 节点。注意：这个值永远不变，但在传播过程中对外暴露的 event.target 属性会骗人---因为有可能存在影dom的情况。

•[[relatedTarget]]：（仅限 mouseover/out 等具有关联对应节点的情况）相关的那个节点（原始值）。 静态配置

•[[bubbles]]：布尔值。决定是否允许进入冒泡。

•[[cancelable]]：布尔值。决定 preventDefault() 是否生效。

•[[composed]]：布尔值。决定事件是否能穿透 Shadow DOM 边界传播。 动态控制标志位  初始状态均为关闭，随 JS 代码执行动态变化。

•[[stop propagation flag]]：封路标记。若为 true，当前节点执行完后，停止传播。

•[[stop immediate propagation flag]]：熄火标记。若为 true，当前节点剩余监听器不执行，且停止传播。

•[[canceled flag]]：撤销标记。若为 true（即调用了 preventDefault），后续将阻止默认行为或触发 UI 回滚。

•[[in passive listener flag]]：静默标记。标识当前是否处于 passive 监听器中（此时忽略 preventDefault）。

•[[dispatch flag]]：运行标记。标识该事件是否正在派发中（防止同一个 Event 对象被重复 dispatch）。 极其重要的内部槽位

•[[Path]]：传播路径列表。 传播路径列表存储在 Event 对象的Path插槽里。 它是静态的。一旦派发开始前计算完成，它就锁死了。即使你在某个回调里把父元素删了，事件传播依旧会沿着已经计算好并岁锁死的路径传播。 列表中的每一项  不是简单的 DOM 节点，而是一个结构体，包含以下7个字段：item (当前哨位)： 具体的 DOM 对象（Window, Document, Element, ShadowRoot 等）。 这是currentTarget在当前的真实指向。target (Shadow 修正目标)： 关键数据。这是算法预先计算好的、在当前的哨位应该对外暴露的event.target。逻辑：如果当前哨位是 Shadow Host，这里就是 Host；如果是在 Shadow DOM 内部，这里就是真实的内部节点。（为了封装性而撒的谎）。relatedTarget (Shadow 修正关联目标)： 同上。预先计算好的、对外显示的event.relatedTarget。touch target list： （仅限 Touch 事件） 经过 Shadow DOM 边界修正后的触点列表。root-of-closed-tree： 布尔值。标记该路径项是否是一个closed模式的 Shadow Root。用于隐私保护。slot-in-closed-tree： 布尔值。用于处理复杂的 Slot 分发场景。invocation-target-in-shadow-tree： 布尔值。标记当前哨位是否位于 Shadow DOM 树内部。 第2，节点上的监听列表 (The Listener Lists) 虽然它们是即时读取的，但它们客观存在于每一个 DOM 节点上。

•持有者：每一个实现了EventTarget 接口的dom对象。

•数据结构：事件监听器列表。

•每个列表项包含字段： type (事件类型) callback (函数或对象) capture (捕获标记) passive (性能标记) once (一次性标记) signal (引爆销毁信号) removed (软删除标记 - 初始为 false)

1.派发与回调调用 经过上面的快速梳理 ，我们已经知道，有三样最重要的东西    事件对象  传播路径表   传播路上的每个节点的监听列表。 现在我们开始发车吧，开启一段有趣的旅程。 嘀嘀嘀 喇叭响了，浏览器引擎启动了主循环，这辆车，要跑两个半程。 1 capture 去程， 从window向下，达到事件目标核心target 2 bubble 回程， 从目标核心 target浮起，一路冒泡到window。 现在我们把车子放慢 再放慢， 停在某一站 第一步 伪装与身份切换 retargeting 车门还没开，浏览器引擎先搞搞伪装，它必须修改event中的数据，以便符合自己在此站点/节点的身份，也为了欺骗此地哨位。 锁定现场 (currentTarget)： 浏览器引擎将 event.currentTarget 指针，锁向当前这一站的 DOM 节点。确定当事人。 撒一个完美的谎 (target 重定向)： 这里涉及到 Shadow DOM 的机密。引擎迅速读取event对象中的path内部槽位中的当前结构中的 shadow-adjusted target内容，覆盖了 event.target。 从之前的学习中，我们知道这个值是根据影dom修正过的值，此时直接覆盖。 shadow-adjusted target的值  针对当前的节点  始终都是正确的，这个覆盖的步骤，是必做的一步。也是每经过一个哨位，都必做的一步。 第二步 精确的时间段控制 捕获阶段 1    车还在去程的路上，离终点还远呢 冒泡阶段 3    车已经返程，快完事了 目标阶段 2  这是最忙碌的换向站点。 实际上  车会两次经过这里， 捕获阶段到达，引擎让捕获组的来，即找出capture: true                                                    冒泡阶段到达，引擎让冒泡组的来，即找出 capture: false       尤其是在目标阶段 ，目标元素上既会执行 capture:true 的监听器，也会执行 capture:false 的监听器；根据最新的规范：通常 capture 监听器先执行，然后再执行非捕获监听器（除非stopImmediatePropagation()等标志打断）。 第三步 提取与快照 此时，引擎敲开当前哨位的门，索要该节点的事件监听列表。 哨位给出原始事件监听列表 引擎拍个照片，形成快照，依据快照进行后续操作。 那么 假如某个回调使用add添加了几个监听，新加的几个  会正常附加在原始事件监听列表尾部， 但是因为引擎是根据 快照  来执行，所以本轮派发没有新添加的份。 假如 某个回调  把它后面的回调移除了，原始事件监听列表中的回调，就真的被移除了，同时移除操作还会将该被移除的回调的removed字段设置为true。看到这里 你可能有疑问，不是被移除了  怎么还能设置它的字段？ 实际上， 不管是原始列表  还是快照， 都是使用的指针， 指向的真正的本体。原始列表中  该字段被标记为软删除，操作的是本体上的该字段，然后移除原始列表中的指针， 本体仍然健在，因为还有快照中的引用在指向它，不能销毁。 另外 快照是按照事件类型匹配后的完整监听器列表，并不是完整的原始事件监听列表。 规范中规定，先取得完整的事件监听列表的快照，然后进行包括type在内的各项比对， 但是在浏览器的实际实现中，已经预先使用了按照事件类型分组 或者其他便捷的组织方式， 所以得到的快照，直接便是按照事件类型匹配好了的列表。 其它条件capture/bubble、once、removed、abort、passive 都在执行阶段对快照 中的每一项逐条检查。 第四步 内部循环 现在  浏览器引擎拿着快照，开始点名核对 指纹核对 type核对（一般在取得快照时，得到的是已经匹配过当前事件类型的列表了） phase  阶段核对，浏览器引擎 根据自己的一套规则，确定当前的所处阶段，以此来过滤回调。 状态检查 removed？  引擎发现这个名字上有removed标记，直接跳过。 aborted？   引擎看了眼abortsignal，标志为真？直接跳过。 关于这个信号，再详细介绍一下，依旧是  监听项本体在堆内存中，Signal 对象 (Controller)也在堆内存里，监听项本体保存对signal的引用。当有js代码调用controller.abort()时，JS 引擎找到内存里的 Signal 对象，把它的aborted字段从false改为true。另外  在abort（）被调用的时候，原始事件监听列表中的该项，也即时被删除  如果还在派发中，则快照上依然保留该项，以防索引bug，但是被标记为软删除 。 实际上，在signal对象内部，也被浏览器注册了一个回调函数，用于主动清理工作，这个内容太超纲了  略过。 当引擎按快照里的顺序，开始检查核对该项时，检查到aborted字段，由快照指针 找到监听项本体，顺着其持有的signal对象的指针，找到signal对象，发现状态为aborted: true ，则直接跳过。 once 机制 浏览器引擎看到once为真的标记，立即把该项从原始事件监听列表中移除。 现在只在快照里了，只能执行这一次。 passive机制 看到passive: true，浏览器引擎给 Event 对象打了个钢印：“忽略反对意见”。 此时你在回调里无论怎么preventDefault()，都是没用的，浏览器甚至还会在控制台贴一张警告条：“别喊了,你就算喊  破喉咙，也没用的。”执行回调与异常抵抗 终于，js引擎出场，调用回调函数，开始执行。 突然，异常出现，某个回调函数崩了，抛出error， 浏览器进行记录，显示在控制台上， 然后开始快照里的下一条监听项的核查比对。 检查与制动 每一个回调执行完，浏览器引擎都会检查event事件对象中的各种标志位，js代码刚才有没有搞小动作？检查 [[stop immediate propagation flag]]如果为真，直接散伙，循环中断，转去判断是否执行默认。检查 [[stop propagation flag]]如果为真，干完这票就收工。快照上的监听项依次干完， 然后转去判断是否执行默认。 默认行为的处理 无论是顺利跑完了全程，还是半路被停止或者是干脆原地散伙，JS 的逻辑阶段都宣告结束。 此时，浏览器引擎会做最后的清算（注意：停止传播不等于取消默认行为）：返回值生成：dispatchEvent会返回一个布尔值。 当且仅当事件可取消(cancelable: true) 且至少有一个监听器调用了preventDefault()时 返回false。 否则   返回true。默认行为： 引擎只看[[canceled flag]]。 哪怕传播在第一站就停止了，只要没人反对（调用preventDefault），浏览器依然会执行默认行为（如跳转链接、提交表单）。 此时，同步的dispatchEvent 调用栈清空并返回。 微任务开始了。

一些重要知识点详解

1.在某个节点，浏览器是如何知道当前所处的阶段？ 当事件传播来到某个  哨位/节点/标签/实现了eventtarget接口的对象/dom元素  ， 当前哨位里，是有原始的事件监听器列表，并没有当前事件动态走向的所处阶段，那么浏览器是怎么得到这个阶段呢？ 很多朋友会说：引擎当然知道  它就是boss 啥都知道，咱只要知道它知道就行了。 话是不错，可但是，我们还是有必要了解一下的。 在事件传播时随身携带的event对象中，内部插槽path存着计算好的路径，每条路径，都是一个列表，里面有7个字段。 引擎使用这种存储方式   Path[0]= target   Path[last]= window     来存储需要走的半程捕获循环： 引擎设置i从Path.length - 1(Window) 开始，递减到1(Target 的父亲)。只要循环在这个范围内，引擎就强行把eventPhase设为CAPTURING-PHASE (1)。 只要没走到索引 0，且我在倒着走，那我就是在捕获阶段目标循环 ：引擎设置i = 0。只要 i 是 0，引擎就强行把eventPhase设为AT\_TARGET (2)。 我踩在终点上了。冒泡循环： 引擎设置i从1(Target 的父亲) 开始，递增到Path.length - 1(Window)。只要循环在这个范围内，引擎就强行把eventPhase设为BUBBLING\_PHASE (3)。 我已经离开索引 0 了，且我在正着走，那我就是在冒泡。 so  并不是 phase 决定了怎么走，而是 “怎么走”决定了 phase。 引擎使用Path，通过控制遍历的起点、终点和方向，从而精准地定义了当前的“时空状态”，这就是它为什么在某一节点，能用自己知道的 所处阶段，去和节点内部的原始事件监听列表的快照进行对比核查的原因。 即使在Shadow DOM存在的情况下，path依然正确有效。 比如需要确定target时 event.target = Path[i].shadow\_adjusted\_target 如果i在影内，修正目标字段里存的就是内部节点。 如果i在影外，修正目标字段里存的就是 Host。总结就是浏览器引擎确定状态的方式，不是“动态感知”，而是“读取预设”。 所处阶段：由循环索引决定。 当前哨位所能看到的目标：由 Path 里的预存字段决定。当前节点：由 Path 里的 item 字段决定。 这就是为什么派发算法如此高效——因为它不需要思考，只需要查表

2.在某哨位 对比核查事件监听器列表时，是全部核查完毕，然后依次执行，还是核查出来一个，就执行一个？ 这是严格按照，揪出来一个 就执行一个的方式。这里有一个极易产生的误解。很多朋友认为浏览器是先把快照里的所有人都撸了一遍，挑出合格的，组成一个新的待执行队列，然后一口气执行完。这是错的。 浏览器的执行逻辑，是严格的“揪出来一个，处理一个”的串行模式。 在for循环的每一次迭代中，引擎做的事情是完整的闭环：点名：根据索引i，从快照里指向第i个监听器。立即核查：“ 你现在被 removed 了吗？”（检查 removed 标记）“ 你的 signal 炸了吗？”（检查 aborted 状态）“ 你是这个阶段的吗？”（检查 capture/phase）立即执行： 如果核查通过，立刻、马上、同步调用你的回调函数。 之所以说是串行，是因为 回调函数的执行，是控制权的移交，必须由js引擎来干活了。浏览器引擎先去抽根烟了。注意：此时，第i+1个监听器还在队列里等着，所有人都不知道它合不合格。后果： 正因为是“执行完一个”才去“找下一个”，所以当前这个回调函数里的操作，能直接决定后续监听器的命运。 比如你在第i个回调里调用了stopImmediatePropagation()，引擎在准备进入i+1循环之前一检查：“欸，熄火标记亮了？”   duang的一声，循环直接 break，第i+1个监听器连核查的机会都没有，大家直接散伙。总结就是：浏览器不是“批处理”，而是严格的“单步迭代”。 快照保证了“人员名单”不许变（后面新来的进不来），但“生存状态”是每一次迭代时实时核查的。

3.在某个节点上，是 1 对 1 还是 1 对 N？ 假如在某个子元素（比如按钮 B）上发生了一个点击事件。事件一路火花带闪电，来到了顶层节点（比如容器 S）。 此时，容器 S 上注册了好几个 click 类型的监听器：有的负责挖坑，有的负责埋雷，有的负责点火，但他们都属于click类型。 那么问题来了：当事件传播到 S 时，是“精准命中”某一个回调执行？还是所有相关的回调都会被执行？ 很多朋友会脱口而出，当然是 1 对 1：“我明明是点的按钮 B，浏览器应该很聪明，只执行那个我当初注册的那个处理 B 的回调吧？” 正确的答案是 浏览器引擎执行的是 1对 N 。 还不是很明白的朋友，可以先看一下前面的  派发与回调调用  这一部分内容。 当事件传播的车开到顶层节点 S 时，浏览器引擎拿出 S 的监听器列表（快照），开始选人干活。 它的筛选标准非常简单粗暴： Type 对吗？ （事件是 click，你监听的也是 click 吗？对。） Phase 对吗？ （我是冒泡过来的，你是监听冒泡的吗？对。） Flag 正常吗？ （没被 remove 吧？signal 没炸吧？正常。） 只要这三条符合，不管你回调函数里写了什么，统统揪出来干活 它的策略就是：全部唤醒，依次执行 那么  怎么办呢？ 当然是在回调函数里判断了，除了有些业务逻辑需要来着不拒，比如访客点击，每个点击都要记录，不需要加判断，除此以外，第一行代码都是身份判断  因为如果不判断，作为回调函数来讲，不管谁的点击事件来了， 它都得执行一遍。 而作为事件本身来说，它只希望自己期望的回调被执行，其他的回调必须拒绝它。 对于基于事件委托的业务逻辑来说，第一行代码永远都是身份判断， 所以，回调函数里的身份判断，万万少不得。 这里我们再引入一个狠角色 stopImmediatePropagation 一个点击事件，可能会有几个点击事件监听项在等着，当某个监听项调用了stopImmediatePropagation， 好了  都别等了  立刻散伙收工。那么问题又来了，假如有好几个监听项在排队， 我不能精确的保证 该在何处调用这个api？这又是一个问题，所以  要保证你所期待的那个监听项是排在第一 或者是你可以明确的知道  应该在哪里调用 比如 两个点击事件项 A是校验 B是提交   你校验不过，可以直接祭出大杀器stopImmediatePropagation，立即阻止了B的排队执行。 其实这个函数通常在第三方库里使用，因为那些库的初始化  都是先于用户代码，所以库在初始化时会抢先注册监听，通过在适当的时候 使用stopImmediatePropagation来一票否决，实现自己的判断 校验 安全拦截等类似功能。

这是全篇文章的第三部分，这部分内容，我觉得还是比较容易理解的，尤其是前半部分，一般新手朋友，读两三遍，应该能收获不少。事件监听器列表，只要花几个小时，了解一下这个表，对于实际开发中的不少问题，就能心中有数，不知为什么 基本上没有人讲解。

第四篇是事件的循环和异步， 我们下一篇再见。

参考列表：

•developer.mozilla.org

•dom.spec.whatwg.org

•html.spec.whatwg.org

•tc39.es

•developer.chrome.com

•w3.org

PART 04

四、 事件的循环和异步

半年前写的这个js的事件系列，一直没完结。中间又写了个V8引擎入门的系列，也写到了执行部分。先把这个js事件系列写完。事件本身是强依赖浏览器的，尤其是循环和异步，所以在深度上，可能会比前三部分略微深入一点。对V8感兴趣的朋友可以看我写的另一个系列 V8引擎精品漫游指南 。

这是js事件系列的最后一个部分。

一 事件的综述

二 事件的完整生命周期

三 事件的传播和处理

四 事件的循环和异步

这四部分已经能覆盖js事件的绝大部分内容了，而且广度和深度都足够。

因为距离前三部分完成已经过了半年，有些术语或者概念，我觉得重要的，可能会再次解释，有些知识点相关比喻，可能会延续使用之前的。

• JS逆向 -- js 事件 事件循环 和异步（一）
  • 异步的精髓绝不是“在物理上同时干两件事”，而是“发起登记 --- 移交控制权 --- 后台等待 --- 未来触发”。它保证了单线程永远在做有意义的运算，而不是死等。

1.事件的循环和异步的综述

我们首先需要搞清楚，事件  循环  异步  这三个东西是什么。事件在第一部分开头就讲过了。

而循环和异步，甚至包括事件，有不少朋友都是糅杂在一起讲的。把它们在概念上分清，有助于我们更好的学习。

事件 Event：

事件本身，没有任何执行代码的能力。在第一部分，我们花了很大的篇幅去讲解事件的本体，也就是 C++ 底层那个庞大的结构体，以及在 JS 层包裹它的那个“代理壳”（Proxy Wrapper）。事件的本质，是系统在某个物理瞬间或逻辑节点发出的一个被动信号。

•当鼠标在屏幕上精准点击了某个按钮，底层操作系统路由了硬件中断，通过进程间通信通知了浏览器，最终在内存里实例化出了一个 MouseEvent 对象。

•这个对象上密密麻麻地盖满了印章（内部插槽）：点击的绝对坐标 [[screenX]]、相对视口坐标 [[clientX]]、事件类型 [[type]]: \"click\"，以及预先计算出来的、锁死在 [[path]] 插槽里的那条从 window 顺流而下再反弹回来的物理传播路径。

这一整套动作，只是在表明了一个事实：有事发生了。

它是一个现场数据载体，但它自己动不了。它躺在内存里，就像是一本写好了“第 3 场第 4 幕，主角被刺”的剧本。至于谁来演、什么时候演、事件自己一概不管，也管不着。

异步  Asynchrony：

很多初学js的朋友以为异步是某种高深的多线程并发技术，其实不然。对于单线程的 JavaScript 来说，异步纯粹是一种在时间维度上的执行策略。

它的核心逻辑用一句话概括就是：“把当下不能立刻完成、或者代价极其高昂的活儿，先在后台登记下来，把当前的主线程执行权让出来，拆给未来去干。”

在传统的同步世界里，执行是死板的。如果有一步需要发起网络请求去获取一个 10MB 的大文件，主线程就必须在原地干等着，直到数据返回。此时整个程序停摆，这就是“阻塞（Blocking）”。

而异步策略则灵活得多：主线程引擎一看，这个网络请求不知道什么时候才能响应。于是它把实际的网络 I/O 工作交给了宿主环境的网络线程，并在通讯录上登记一下：“等网络线程把数据拿回来了，触发这个回调函数。” 随后，主线程立刻转头去执行后面的同步代码。

异步的精髓就在于“发起登记 -> 移交控制权 -> 后台等待 -> 未来触发”。它是一种让资源利用率最大化的智慧，保证了单线程永远在做有意义的运算，而不是死等。

异步主要解决的是I/O 密集型任务的阻塞问题。对于 CPU 密集型任务，单线程的 JavaScript 本身仍然会阻塞，这时候需要使用 Web Worker 等技术。

事件循环  Event Loop：

这是第四部分真正的主角，首先要明确：事件循环，不是 JavaScript 引擎（比如谷歌的 V8）的一部分。

在 V8 引擎源码中，会看到精妙的解释器、优化编译器，以及处理调用栈（Call Stack）的机制。但是，在 V8 里面绝对找不到任何关于 setTimeout 队列、网络请求回调或者事件循环 while 循环的底层实现。

JS 引擎本身，是一个极度纯粹的执行机器。  比如  chrome中的V8  只负责解析、编译和执行 JavaScript 代码，以及垃圾回收和内存管理。所有与外部世界的交互 —— 定时器、网络请求、DOM 操作、事件监听 —— 全部由宿主环境提供。

而js引擎，比如v8，只有看到眼前的同步代码（当前的执行上下文栈）时，才会开始疯狂工作，直到把眼前的逻辑跑完、调用栈彻底清空。一旦栈空了，JS 引擎就会陷入无所事事的休眠状态，它自己既不知道接下来还有没有网络请求要来，也不知道用户有没有点鼠标。

真正让这一切运转起来的，是包裹在 JS 引擎外层的宿主环境（Host Environment）。在浏览器里，这个宿主是 Blink 渲染引擎和底层的多线程架构，在 Node.js 里，则是异步事件驱动库 libuv。

而事件循环，就是宿主环境派驻在 JS 引擎身边的一个“总调度师”。

浏览器作为宿主环境，在 JS 引擎之外维护着多个独立的线程：定时器线程、网络 I/O 线程、UI 渲染线程等等。当外面的底层线程把活儿干完了，总调度师就会把对应的 JS 回调代码塞进他手里的“任务队列”。

总调度师的工作极其机械死板，它持续监控着 JS 引擎的调用栈。只要 JS 引擎一跑完眼前的代码，把调用栈空出来，总调度师就会立刻走过去，翻开任务队列，抽出下一个排在首位的任务，塞到 JS 引擎的执行栈里：“歇够了没？该处理这段逻辑了，马上执行”

注意，这里说的 任务队列 并不是一个单一的队列，而是包含了不同优先级的多个队列，其中最重要的就是我们后面还会详细讲解的宏任务队列和微任务队列，关于任务队列，在第一部分开头也有讲过。

task queue / microtask queue  这里为了方便理解，暂时沿用‘宏任务’和‘微任务’这两个常见说法。

现在，我们将这三个概念放在在一起：

1.事件 (Event) 负责“宣告发生”，它是底层现场数据的静态快照。

2.异步 (Asynchrony) 负责“延后交接”，它是跨越时间的执行与状态挂起策略。

3.事件循环 (Event Loop) 负责“统筹轮转”，它是宿主环境在宏观上掌控的排班排程制度。

它们三位一体，严丝合缝地配合在一起。事件在外部触发，异步将结果包装后在队列里排队，而事件循环在中间掌控传送带的节奏，将一个又一个任务送入 JS 引擎的处理流水线。正是因为宿主环境在外部打好了这套精妙的调度配合拳，JavaScript 这个单线程的执行器，才能在前端庞大、复杂的动态世界里，撑起丝滑流畅的宏大场面。

2.dispatchEvent返回之后

在第三部分的结尾，随着事件派发之车跑完全程，所有的 capture（捕获）和 bubble（冒泡）监听器依次执行完毕，dispatchEvent 函数终于返回了。

但是，事件处理并没有画上句号，从底层系统的视角来看，真正的关键时刻此时才刚刚开始。当同步代码的战斗完成，留在战场上的并不是风平浪静，而是一个需要清理和调度的庞大状态网。

2.1 执行栈 Execution Context Stack 和 微任务检查点

我们先看看主线程的核心工作区域  执行上下文栈 Execution Context Stack，即调用栈。

当事件相关的回调函数被压入调用栈并执行完毕后，调用栈会一层层退散。

但是，dispatchEvent 函数本身的返回，并不绝对等于执行栈彻底清空。这里我们需要精确的描述出三条不同的物理路径，它们在底层的处理逻辑有着本质的区别：

用户真实点击（原生物理交互）
这是纯正的异步调度。当用户在硬件上完成点击，浏览器将其包装成一个宏任务推入任务队列。当这个任务出队并在主线程上执行时，最外层并没有其他 JS 脚本在压着栈。因此，当 dispatchEvent 执行完毕返回、且该任务对应的领域执行上下文（realm execution context）被弹出时，在规范的抽象状态机判定中，JavaScript 执行上下文栈将彻底回归到为空（Empty）的状态。

注：领域realm是规范中的概念，对应一套完整的全局内置对象体系。有助解释不同脚本/模块之间的原型链与全局隔离等高级语义（如 iframe 之间的差异）。大多数情况下，Realm（规范概念） = Context（V8 物理实现）。

脚本触发的点击（调用 element.click()）
这是一种“激活行为”，它的本质是一次同步的函数调用。当你在一段正在运行的脚本中写下 btn.click() 时，浏览器会无缝切入事件派发流程。这就表示，当派发结束、click() 返回时，控制权只是交还给了外层那段还没跑完的同步代码。此时，执行栈并没有空，最初触发它的那行脚本依然在栈底压着。

手动派发事件（调用 element.dispatchEvent(event)）：
这属于纯粹的合成事件派发（Synthetic Event Dispatch）。它和 click() 类似，同样是完全同步的，会直接在当前的执行栈里压栈执行。但它与 click() 的核心区别在于：element.click() 会同时触发事件派发和浏览器原生默认激活行为（如复选框勾选、链接跳转），而 element.dispatchEvent(event) 仅会执行纯粹的事件派发流程，绝对不会自动触发与该元素关联的原生默认激活行为。

那么，我们为什么要如此精确精准的描述执行栈的清空状态呢？

因为在 WHATWG 规范中，存在一个极其严格的判定关卡——微任务检查点（Microtask Checkpoint）。

微任务（如 Promise.then 的回调、MutationObserver）并不是写下就会立刻执行的。规范给出的底层规则是：微任务的就地清空由 HTML 规范的 Clean up after running script 算法死守。只有当一个独立的回调执行完毕、JavaScript 执行上下文栈彻底为空，且当前未处于“正在执行微任务检查点”的保护状态时，宿主环境才会立刻拉响警报，触发微任务检查点。

一旦满足条件，主线程就会立刻停下宏观的任务轮转，转头去把微任务队列里的所有积压一口气清理干净。
注意，这里规范会开启一个底层的重入保护锁（将 performing a microtask checkpoint 标志位置为 true），这个锁的作用是防止微任务检查点被递归调用，避免出现栈溢出，如果在清空微任务的过程中，又动态追加了新的微任务，它们会被继续挂载到队列末尾并在本次检查点中被强制解决掉，直到队列连个渣都不剩。如果执行栈因为 btn.click() 或手动 dispatchEvent 被外层脚本压住，微任务就只能憋在队列里继续等待。

2.2 其他宏任务正在排队

就在主线程认真的在执行栈里处理 dispatchEvent 的这几毫秒甚至几十毫秒内，外面的世界也是同样在忙碌。

主线程在执行同步代码时，对外界的变化是无法即时响应的。但是，包裹着它的宿主环境（浏览器）是一个庞大的多线程架构。在这个短暂的时间差里，后台的各个线程可能已经发生了许多事情：

•网络 I/O 线程刚刚把一张图片下载完，触发了 load 数据的就绪信号。

•定时器线程发现一个 setTimeout 的 1000ms 倒计时刚好归零。

•用户烦很大的又在键盘上敲了一下，引发了新的输入信号。

这些在后台已经干完的活儿，主线程此时分身乏术。于是，宿主环境会将它们的回调逻辑分别包装成一个个崭新的宏任务（Macrotask），悄悄地塞进对应的任务源（Task Source）队列中，在门外静静地排队等候临幸。

2.3 内存树已变与渲染时机

在刚才的事件回调里，你的代码可能执行了类似 button.style.backgroundColor = 'red' 或者 document.body.appendChild(div) 这样的操作。

这里要注意：执行完这些代码的瞬间，屏幕上的颜色并没有变成红色，新的元素也没有立刻出现在显示器上。

主线程对 DOM 的修改，仅仅是同步改变了浏览器内存中逻辑数据树（DOM Tree）和样式规则树（CSSOM）的状态。修改内存是在极短时间内同步完成的，但这并不意味着浏览器会立刻把变化“画”到显示器的像素点上。

从高层流程上理解，页面的视觉更新需要走一遍完整的渲染管线：重新计算样式（Style）、重排布局（Layout）、绘制图层（Paint）以及最终的图层合成（Composite）。

但从底层调度来看，浏览器的渲染是由自身的事件循环和“渲染时机（Rendering Opportunity）”共同决定的。

浏览器非常精明，它通常会结合显示器的刷新率（例如 60Hz 对应约 16.6ms 一帧）来评估性能。如果你在一个宏任务里连续修改了 100 次颜色，浏览器也绝对不会频繁走 100 次渲染管线。它会等待当前的同步任务执行完毕并清空所有微任务，然后在本次事件循环的渲染评估阶段，判定“现在到了适合刷新画面的时机”，才会启动渲染更新。而我们常说的 requestAnimationFrame（rAF），正是在浏览器决定重绘的渲染管线启动前夕、样式计算和布局之前，被集中调用的特权拦截器。

2.4 宿主调度器重新接管

综合以上所有的内部状态，我们可以得出一个至关重要的结论：

当程序的“这一轮”同步逻辑宣告结束时，主线程并不会自己凭空旋转着去寻找下一段代码。 负责执行的底层引擎本质上只是一个高级的运算器，它内部并没有掌控全局的死循环。当微任务打扫完毕、渲染评估完成后，如果没有新的宏任务就绪，JS 引擎就会暂时陷入静默的休眠状态，等待调度器唤醒。

真正让整个网页保持生命力、决定“下一轮”该谁上场的，是宿主环境的调度器（Scheduler）。

在这一刻，调度器重新接管了最高控制权。它严格按照 HTML 标准中规定的事件循环标准处理模型（Processing Model）节拍，开启了一轮极其精准的状态盘点：

•宏任务落幕：当前作为运行单元的宏任务彻底宣告终结，并将其从当前执行任务清空。

•宏观微任务清算：在宏任务结束后，强制触发一次完整的 Microtask Checkpoint。由于宏任务已结束，此时执行栈必然为空，宿主环境会彻底强行清空整个微任务队列（包括执行期间新产生的微任务）。

•渲染时机评估与更新：盘点当前距离上一次屏幕刷新过去了多久。如果刚好命中了硬件的刷新节拍（Rendering Opportunity），则立刻启动渲染更新步骤：依次执行当前的 rAF 回调，并无缝推送页面走完计算样式和重排布局的渲染管线。

•下一个宏任务决策：审视各个不同优先级任务源队列（Task Source Queues）的积压情况，根据实现定义的调度策略（现代浏览器通常优先抓取更紧急的用户交互任务以保证响应性），选择最老的可运行任务，重新将其推入 JS 引擎主线程执行。

3.事件循环到底是在循环什么

很多前端初学者在被问到“什么是事件循环”时，脑海中往往会浮现出这样一幅画面：JavaScript 引擎（比如 V8）的底层源码里，写着一个类似 while(true) 的无限循环。它就像一个不知疲倦的纺车，没日没夜地在原地疯狂空转，疯狂地去扫描任务队列里有没有新代码，一旦抓到就立刻烧热 CPU 去执行。

这个认知，在底层逻辑上是完全错误的。

在底层的真实世界中，事件循环不是 JS 引擎内部的空转，而是宿主环境（浏览器 Blink 引擎 / Node.js 的 libuv）精心设计的一套“调度协议”与“状态盘点制度”。 在没有任务处理时，事件循环不仅不会空转，反而会通过底层的操作系统内核（如 Linux 的 epoll、macOS 的 kqueue 或 Windows 的 IOCP）将主线程彻底挂起进入休眠状态，让出 CPU 资源。只有当底层硬件中断、网络数据包到达或定时器到期时，主线程才会被操作系统瞬间唤醒。

3.1 非抢占式调度和调用栈的绝对控制权

要理解事件循环在循环什么，首先要明白主线程在运转时的核心规则：JavaScript 的代码执行是极其依赖执行上下文栈（Call Stack，即调用栈）的。而这个执行机制，是典型的“协作式调度（Cooperative Scheduling）”，即常说的“非抢占式”。

什么是协作式（非抢占式）？

在操作系统的层面，一个线程正在算账，操作系统可以通过硬件中断强行把这个线程掐断，把控制权夺走去干别的，这叫抢占式。但 JavaScript 主线程不吃这一套，它遵循的是运行至完成（Run-to-completion）的特性。

当宿主环境把一段 JS 脚本推上主线程，V8 引擎开始解析并压栈执行的瞬间，在 JavaScript 的逻辑层面，只要当前调用栈中仍有代码正在执行 ，宿主环境就无法插入新的js任务，无法从外部打断它：

•哪怕此时用户把鼠标点烂了，引发了海量的物理中断；

•哪怕此时网络下载完了一百个文件，急需触发回调；

•宿主环境（浏览器）也只能在旁边默默看着，绝对无法在函数执行的中途强行插播代码。

在单线程的限制下，宿主环境想要重新夺回主线程的控制权、去看看“接下来的大局该怎么安排”，唯一的契机，就是当前 JavaScript 执行上下文栈彻底变为空（Empty）的瞬间。（注意：栈空后，引擎会先清空微任务队列，随后控制权才真正交还给下一步调度。）

只有当当前的脚本跑完，最后一个函数弹出调用栈，控制权才会从 V8 引擎的手里交还给宿主环境的调度器（如浏览器的 Blink Scheduler）。在这个绝对空白的转折点上，宿主环境才有机会真正睁开眼睛，开启它的状态盘点。

3.2 循环的本质是“状态盘点”：

事件循环所谓的“一圈”，绝非无脑的代码扫描，本质上是宿主环境在控制权交还的空白间隙，严格按照 WHATWG HTML Living Standard 规范中的事件循环处理模型（Processing Model），进行的一场高密度的状态盘点与大清算。

它手里拿着一张严密的底层清单，按部就班地核对以下四个维度的时空状态：

一 宏任务源盘点（Task Source Check）

在规范的严谨定义中，并不存在一个名叫“宏任务队列”的单一实体。规范使用的核心术语是 任务源（Task Source），例如：DOM 操纵源（DOM manipulation）、用户交互源（User interaction）、网络源（Networking）、导航与遍历源（Navigation and traversal）等。

规范规定：每一个 Task Source 必须关联到一个具体的 Task Queue（任务队列）。但在浏览器具体实现时，为了优化调度，可以将多个不同的 Task Source 塞进同一个物理的 Task Queue 里（例如，将网络任务源与导航任务源合并到同一个物理任务队列中）。

此时，调度器会在这里进行实现定义（Implementation-defined）的优先级裁决。通常情况下，为了保证页面的丝滑响应与防冻结，浏览器会尽量优先处理用户交互相关任务。

调度器会首先以实现定义的方式从多个任务队列中选出一个队列，然后从该特定队列中取出最老的一个可运行任务（Runnable Task），将其推入主线程的调用栈。
规范在此处有一个硬性限制：无论采用何种优先调度策略，同一任务源（Task Source）内部的任务顺序，绝对不可被打乱。

二 微任务全面清算（Microtask Checkpoint）

当上一步的宏任务执行完毕，调用栈再次归零的瞬间，调度器会立刻切入微任务检查点（Microtask Checkpoint）。

这里要注意，微任务检查点不仅会在任务执行结束后触发。根据 HTML Standard 中的 Clean up after running script 算法，在脚本或回调函数执行完毕且判定执行栈为空时，同样会触发微任务检查点。

在这一步中，调度器会盯着事件循环的微任务队列（Microtask Queue），开始清空。

这个盘点是非常彻底的：它循环从队列中取出最旧的微任务交由引擎执行，直到队列为空。如果在清空微任务的过程中，动态追加了新的微任务，它们会被继续挂载到当前队列末尾，并在本次检查点中被继续执行。

前面也讲过了，这里再次重复一下，规范通过将 performing a microtask checkpoint 标志位置为 true（重入保护锁），防止了清空算法在嵌套执行时被重复进入。但这并不影响当前正在运行的微任务清空循环：如果在执行过程中动态追加了新的微任务，它们会被挂载到队列末尾，并在当前循环中立即执行，直到队列彻底清空。

三 渲染时机评估（Rendering Opportunity）

微任务彻底打扫干净后，主线程将迎来事件循环中最精明的一个阶段。调度器会开始盘点时间的流逝：
“当前文档是否迎来了渲染时机（Rendering Opportunity）？”

需要注意，是否渲染是针对每个文档（Document）和可导航上下文（Navigable）独立评估的，绝不是事件循环每转一圈就盲目重绘一次。调度器在宏观上会进行多维过滤：

•目标文档当前是否处于可见状态（例如 visibilityState 是否为 hidden）？

•距离上一次渲染是否过于接近，尚未到达显示设备的下一次刷新节拍？

•本轮更新是否根本不会产生任何可见效果？

注：JavaScript 的执行速度极快，事件循环（Event Loop）一秒钟可能转了几千圈。但是，绝大多数普通显示器的硬件刷新率是 60Hz（每秒刷新 60 次），也就是大约每 16.6 毫秒屏幕才会物理重绘一次。

如果评估结果判定当前不适合进行渲染更新，调度器会直接跳过本次视觉渲染流程，迅速开启下一轮任务提取。反之，如果浏览器判断当前存在渲染时机，它就会进入规范中的 Update the rendering 流程。

关于渲染更新的内容，我们在后面将专门用一小节来进行详细讲解。

四 空闲节拍盘点（Idle Period）

如果当前窗口的事件循环中已经没有任何可运行的任务（No Runnable Task），意味着主线程在这一刻彻底闲了下来。
面对下一个硬件刷新信号到来前的这段珍贵间隙，且浏览器判定当前适合执行低优先级工作时，调度器便会开启空闲周期（Idle Period）。

在进入空闲周期前，调度器会利用标准算法，盘点出一个极其精确的剩余时间截止牌（Deadline）。这个 Deadline 的计算极为严格：

•它首先给出一个默认上限——“当前时间 + 50ms”，以确保一旦用户突然产生新的输入，主线程能够在合理时间内迅速响应；

•随后，它会去翻看定时器账本，找出所有待处理定时器中最早到期的那个时间点；

•如果此时还存在即将到来的渲染机会，它还会结合下一次渲染节拍进一步收紧时间预算。

调度器会综合这些时间点，并取其中最早的那个作为最终 Deadline。最终计算出的安全截止时间会被注入到 IdleDeadline 对象中。

调度器带着这个截止牌，开始按序调用那些排在空闲队列里的 requestIdleCallback（rIC）回调。回调函数中的代码可以通过 deadline.timeRemaining() 实时查看自己还剩余多少可用时间。一旦发现时间预算即将耗尽，就应主动结束当前工作并交还控制权，从而确保这些低优先级后台任务不会拖累高优先级的用户交互与流畅的动画渲染。

这里我们需要详细的说一下，在某一轮事件循环中，当微任务被清空后，进行渲染更新的判断，当判断结果为不需要，那么就继续事件循环，看任务队列取任务，如果队列中没有可执行的任务了，那么就进入空闲周期，首先给出初始的50毫秒，然后看是否有定时器，假如没有定时器，那么就看是否有待定渲染 pending render，假如有，那么就看下依次渲染边界，在60赫兹下，是16.7毫秒。 可能有朋友会疑惑，在进入空闲周期之前，渲染更新也判断过了，队列里也没有可执行任务了，这才刚进空闲周期，啥也没干呢，怎么就又要判断是否有待定渲染？ 这个待定渲染是什么？ 在微任务清空后，update the rendering  判断的是本轮次循环的渲染机会，就是要不要真的更新渲染。 进到空闲周期以后， pending render 是在问“同一个事件循环里，是否还存在需要保留渲染边界的页面/窗口状态”，在规范层面，一个“Window event loop”是可以服务于多个“Document”。 比如，主页面 A.com 中嵌入了一个同源的 iframe B.com，那么很大可能，它们就是同享一个主线程，同一个事件循环。 浏览器通过自己对待定渲染的判断，加上是否有定时器，然后把可用的空闲周期的时间Deadline，从最初的50毫秒，按照最小的时间收紧。 假如，页面完全静止 无定时器  无任何待定渲染，空闲周期为50毫秒。 假如，刚刚渲染完毕，就进到了空闲周期，60赫兹下，此时距离下次硬件刷新还剩16.7毫秒， 无定时器，浏览器判断有待定渲染，那么，空闲周期为16.7减去1，15.7毫秒的空闲周期，减去的1毫秒，为渲染准备时间，规范没说具体值，但一般实现 比如chrome 都是使用1毫秒的渲染准备时间。 假如，60赫兹下， 距离下次硬件刷新还剩8毫秒，进到了空闲周期，无定时器，浏览器判断有待定渲染，那么，空闲周期为8-1=7毫秒。 最后，是一个边界情况，假如最后算出的Deadline小于等于0，那么就直接跳过了空闲周期。

至此，事件循环的一次完整“盘点”便宣告结束。
它并不是一个在后台疯狂旋转、不断扫描代码的无脑 while(true)，而是一套由任务提取、微任务清算、渲染评估以及空闲调度共同组成的精密状态机。每当调用栈清空、控制权重新回到宿主环境手中时，这套盘点制度便会再次启动，周而复始地维持整个 Web 世界的运转。

3.3 僵尸的入土时机：

我们在第三部分讲解 removeEventListener 的底层原理时，我们提到过一个辣手的并发场景：假设在一个事件派发（Dispatch）的遍历执行过程中，前一个回调函数竟然把紧排在它后面的监听器给注销了，这会引发致命的数组遍历索引越界（Concurrency Bug）。

为了解决这个问题，浏览器底层采用的是一种极其克制的“软删除”策略：当你在 JS 代码里调用 removeEventListener 时，底层的 C++ 引擎并没有立刻把那个监听器项从内存数组里物理剔除。它只是温柔地在那个表项上打了一个勾：removed: true。

这种软删除策略虽然完美保障了正在执行的事件派发不被打断，但也留下了一个悬念：这些已经在逻辑上宣告死亡的“僵尸监听器”，它们极其厚重的 C++ 结构体、JS 包装壳以及缠绵在一起的闭包（Closure）上下文，到底在什么时候才能真正入土为安，释放内存？

这就是一场跨越两大引擎的精密联动。

第一步：派发落幕与宿主的“名册清洗”

有些初学的朋友误以为这些标着 removed: true 的僵尸会一直赖在监听器列表中，直到触发垃圾回收。事实并非如此。

真实的情况是：当当前的事件派发循环（Event Dispatch Loop）刚一结束的瞬间，Blink 引擎（宿主环境）就会立刻展开行动。
底层的 C++ 代码会重新遍历一次 EventListenerMap，将所有带有 removed: true 标记的表项，从列表中物理剔除（Erase）。

注意，前面一二三部分中，我们说的 [[eventlistenerlist]] 是规范中的术语，  现在说的EventListenerMap  是在 C++ 底层的真身。这里进行了区分。可以将它们认为是 一个是规范中的术语，一个是实现中的具体名字。

这一步极其关键，它相当于宿主环境主动剥离了联系，彻底斩断了 C++ 底层指向上层 JS 回调函数对象的“强引用指针”。

第二步：两套独立的堆内存

虽然名册被清洗了，但此时，内存并没有真正释放。
在浏览器的复杂架构中，存在两套截然不同的内存管理空间：

•Blink 的堆内存：由 Blink 引擎自己的垃圾回收器（Oilpan）管理，存放 C++ 层的 RegisteredEventListener 对象。

•V8 的 JS 堆内存：由 V8 GC 管理，存放 JS 层的函数对象以及极其吃内存的闭包上下文。

随着第一步强引用被斩断，这两个对象虽然还停留在各自的物理内存中，但在系统的逻辑图谱里，它们都已经沦为了没有任何根节点（GC Roots）指向的绝对孤岛。

第三步：空闲节拍的后台清扫与物理超度

现在万事俱备，只欠 GC（垃圾回收）。
虽然 Oilpan 和 V8 GC 在内存有压力时随时可能触发回收，但在现代浏览器中，调度器更倾向于寻找一个“不打扰主线程主线任务”的完美时机——这就是事件循环的空闲周期（Idle Period）。

当事件循环走完了前面的部分（宏任务空了，微任务清了，渲染也搞定了），进入短暂的无所事事时期，Blink 调度器会通过一层底层的 API 桥梁，向 V8 引擎发送一个明确的空闲通知，并附带上精确的剩余时间配额：
v8::Isolate::IdleNotificationDeadline(deadline)

是不是感觉很熟悉？ 这就是前面刚刚讲过的 空闲周期。

这行代码本质上是宿主环境在对v8下达命令：“现在彻底空闲了，距离下一次忙碌还有精确的 X 毫秒。带着你的保洁团队，趁现在赶紧去打扫战场！”

得到了时间配额，V8 引擎的垃圾回收机制（V8 GC）便利用这几毫秒的隙缝，开启了它的大扫除：

1.纯粹的可达性判定：V8 严格的垃圾回收算法（可达性分析），开始顺着内存的引用链一路查下来。在 GC 的眼中，没有业务逻辑，它也不认识什么是 removed 标记，它只认冰冷的引用链路。

2.确认孤立：由于 Blink 早已在第一步清除了名册断开了 C++ 引用，且 JavaScript 用户层也没有任何变量持有这些监听器，V8 确认这些函数和闭包是彻底不可达的无用垃圾（Unreachable）。

3.终极的物理释放：随着垃圾清理程序的扫过，这些赖在堆里多时的 JS 包装壳与厚重的闭包包袱，终于迎来了物理层面的超度。它们占据的内存单元被彻底抹平，交还给操作系统。与此同时，Blink 的 Oilpan 也会在自己的调度下，将底层的 C++ 壳子一并回收。

至此，一个 JavaScript 事件结束了。

它在 C++ 底层被实例化，经历了捕获与冒泡，在同步的调用栈中爆发，在异步的宏任务队列里排队，在微任务检查点的闸门前博弈，最终在渲染管线后的空闲时间中，被底层的双引擎联合清除掉了。

这不仅是一个单纯的 API 机制，更是宿主浏览器、调度器、JS 引擎在时间和空间维度上，精密配合的操作流程。

4.任务

在理清了事件从信号触发到路径计算的宏观旅程，以及节点上监听列表的生存清理机制后，我们终于来到了整个宿主环境最核心的宏观调度核心——事件循环的处理模型（Processing Model）。

现在，我们翻开宿主调度器的排班表，来看看事件循环中绝对的台柱子：任务（Task，在前端开发中常被通俗地称为“宏任务”，因为task和宏任务 这两个名称混用并没有什么歧义，所以我们并不严格区分它们）。

4.1 什么是任务（Task）

从控制权的视角来看，任务是一个占用主线程执行权的、在逻辑上不可分割的完整运算单元。

规范里的事件循环每一轮，都会从某个包含可运行任务的任务队列中，按实现定义的方式选出一个队列，再从中取出最老的可运行任务交给宿主环境执行；同一 task source 内的任务顺序不会被打乱。任务一旦开始执行，JavaScript 就会按“运行至完成（run-to-completion）”的语义，把当前同步逻辑连续跑完。

在单线程协作式（非抢占式）调度的机制下，任务的执行具备两个核心特征：

1.控制权的独占性： 无论这段任务内部有多少层嵌套函数，或者进行了多么复杂的循环运算，只要当前的执行栈还没有被彻底清空归零，主线程就无法被外部强行插播或抢占。此时，外界的一切物理中断、网络就绪信号、甚至是紧急的重绘请求，都必须在主线程大门外静静排队。

2.执行的完整性： 遵循 JavaScript 经典的“运行至完成”（Run-to-completion）语义。只有当这一个任务所有的同步代码全部运行结束，执行栈彻底归零时，这一轮任务才算真正告一段落。在此之后，最高控制权才会交还给宿主调度器，事件循环才拥有进入后续评估、清算微任务以及更新渲染（Update the rendering）的机会。

因此，单个任务的执行时长直接决定了网页的响应质量。根据 Long Tasks API Level 1 的定义，持续时间超过 50 毫秒 的任务会被视为 long task；这里的 50ms 是监测阈值，不是引擎的硬性切断点。JavaScript 引擎不会在达到 50ms 时自动中断代码，它只会一直运行到任务自然结束，而这期间事件循环就会被占住，页面便容易出现卡顿、掉帧和交互延迟。

4.2 任务的来源与任务源（Task Source）

JavaScript 引擎本身是一个极度纯粹的代码执行器，并不包含定时器或网络 I/O 的底层物理线程。事件循环里排队的所有任务，本质上都是由外层的宿主环境（在浏览器里是渲染引擎如 Blink，配合底层多进程架构）在处理完各类底层物理或逻辑事件后，异步推送进来的。

在 HTML 规范中，任务并不是简单地堆放在一个扁平的队列里，而是通过任务源（Task Source）进行分类。规范规定，来自相同任务源的任务必须按顺序进入相同的任务队列，但浏览器可以拥有多个不同的任务队列。

这里要注意，规范并没有将特定的任务源定义为绝对的“最高优先级”。 选择哪一个任务队列进行轮询完全由具体的实现（Implementation-defined）决定。但在实际的浏览器（如 Chrome）中，为了防页面冻结、提升交互响应性，调度器通常会更多更积极地去处理与用户交互相关的任务队列（如输入事件），并在后台任务队列快要“饿死”时进行防饥饿（Anti-starvation）调度。

这些任务源在规范中有着清晰的界定：

•用户交互任务源（User Interaction Task Source）： 用于处理用户产生的物理输入，例如鼠标、键盘等交互行为。像 click 这样的输入事件，规范明确要求使用用户交互任务源来派发。keydown 这类输入事件也属于同一类用户交互相关任务。需要注意的是，scroll 事件和普通输入事件不完全一样。 CSSOM View 明确说明，scroll 事件和 resize 事件会与 HTML 的事件循环集成，并且与 animation frames 同步。也就是说，滚动相关事件更像是跟着渲染帧节拍统一派发，而不是完全按普通任务那样“来了就排队、立刻执行”。

•计时器任务源（Timer Task Source）： 对应 setTimeout() 和 setInterval()。很多初学者会误以为写下定时器以后，JavaScript 会“等一会儿再继续执行”；其实不是。主线程只是先向宿主环境登记一个定时要求，真正的倒计时由浏览器独立完成，时间到了以后，再把回调包装成任务放入对应队列。规范还规定：当定时器嵌套层级超过 5 层时，最小间隔会被强制限制为至少 4ms。

•网络任务源（Networking Task Source）： 用于处理网络活动相关任务。比如 XMLHttpRequest 的状态变化、资源加载完成等情况，都会由宿主环境在网络结果就绪后，把相应回调安排进任务队列。网络请求真正耗时的部分不发生在 JavaScript 线程里，JavaScript 只是负责最终处理结果。

•导航与历史遍历任务源（History traversal task source）： 用于处理浏览器导航、前进后退、会话历史遍历这一类工作。history.pushState(...) 这类操作可以理解为脚本层对历史状态的同步修改；它并不等同于一次真正的历史遍历任务。

•消息投递任务源（Posted message task source）： 用于不同执行上下文之间的消息传递。例如 postMessage()、MessageChannel、MessagePort 这类机制，都会在目标上下文收到消息后，把对应的消息事件放入消息相关的任务队列中等待执行。

5.微任务

在前面我们讲了任务（Task）如何作为宿主环境的“外层传送带”，把外部世界的动静一轮一轮送入主线程。然而，在主线程之内，JavaScript 运行时还藏着一条更细、更快、也更容易制造时序错觉的微观通道——微任务（Microtask）。

在标准规范中，任务与微任务有着不同的分工与血统：任务负责宏观轮转，而微任务则由微任务检查点统一清算。如果说任务是宿主环境（浏览器 C++ 层）派遣给主线程的“外部劳务”，那么微任务更像是 JavaScript 引擎内部（如谷歌 V8 的 v8::MicrotaskQueue）直接调度的嫡系子弟。它们的运行，不是靠“等下一个大活”，而是靠“当前同步代码一旦退场，就立刻就地清理”。

5.1 最重要的关卡：微任务检查点（Microtask Checkpoint）

微任务并不是在任意时刻乱入的。它们被一道非常严格的闸门所控制，这道闸门就是 HTML 规范中的 perform a microtask checkpoint 算法。这个算法的核心特征只有一句话：一旦开始，就持续处理微任务队列，直到队列为空。

为了深入理解微任务检查点的运转，我们可以将其底层微观机制归纳为以下核心要点：

1.防重入保护锁（Re-entrancy Protection）： 规范在实现上专门设置了一个名为 performing a microtask checkpoint 的内部布尔标志位。当检查点启动时，该标志位被置为 true。如果此期间有任何机制试图再次触发检查点，算法会直接闪避返回。这种设计是为了防止检查点在自己运行时又被自己递归触发，避免重入打架导致执行栈自我踩踏或栈溢出。

2.“栈空”才是真正哨兵： 微任务检查点的触发时机并不是单一的“宏观任务边界”。更准确地说，HTML 的脚本清理步骤（Clean up after running script）会在 JavaScript 执行上下文栈为空时触发微任务检查点。标准特别指出，这类算法甚至可以在间接场景中重入运行（例如脚本派发了一个带监听器的事件）。也就是说，“执行栈变空”才是唤醒这支清道夫部队的真正哨兵，而不是“任务”这个大壳子本身。

3.先进先出（FIFO）与 一清到底 ： HTML 的清空算法是严格按照 oldestMicrotask（最老微任务）的顺序依次取出并运行的。如果在执行某一个微任务的过程中，代码又动态追加（如再次调用 Promise.then 或 queueMicrotask）了新的微任务，这些新兵会被直接塞进队列的末尾，并继续在当前同一轮检查点内被强制连续处决，直到队列彻底变为空为止。

4.长任务阻塞而不是死锁： 这种“清到见底”的机制也解释了为什么微任务一旦写成“无限补货”（例如一个无限自我调用的微任务环），就会形成非常危险的饥饿效应。过多的微任务会像海量的同步代码一样彻底占满主线程。此时，主线程长期停留在微任务清算阶段，事件循环无法向下轮转，导致浏览器无法做自己的事，包括无法响应交互、无法重绘画面。严格来说，这属于主线程被微任务长期占有所引起的“阻塞/饥饿”，而不是传统多线程意义上的死锁。

微任务检查点并非只在“任务边界”触发。根据 HTML 规范，每次 JavaScript 回调结束且执行上下文栈为空时，都可能立即执行微任务检查点。因此，在同一次原生事件派发过程中，微任务也可能在监听器之间“插播”。这一机制正是很多异步时序差异与 bug 的来源。

任务边界不是唯一的清算点

很多事件循环教学会给出一个简化的规则：

“微任务在每个宏任务结束后、下一个宏任务开始前执行。”

这对理解 setTimeout 与 Promise 的优先级非常有用，但不能将其绝对化，因为容易把“任务边界”误当成唯一触发点，而忽略了“执行栈为空”这一真正关键的条件。

规范：clean up after running script

HTML 标准在 §8.1.4.3.2 Clean up after running script 中明确规定：

… If the JavaScript execution context stack is now empty, perform a microtask checkpoint.
（如果 JavaScript 执行上下文栈现在为空，则执行微任务检查点。）

这表示：任何一个 JS 回调执行完毕后，引擎都会执行清理步骤；只要此时 JS 栈为空，微任务检查点就会被触发。这也解释了为什么在一些事件回调之间，微任务可能会被提前清算，而不必等到“整个任务结束”。

dom标准 ：定义事件派发算法：按捕获-目标-冒泡顺序同步调用所有匹配的监听器，不负责插入微任务检查点。

html标准：定义脚本执行和清理规则：在每次 JavaScript 执行上下文栈清空时执行微任务检查点

DOM 事件派发算法本身并不负责微任务调度。它只是同步地逐个调用函数，而微任务检查点之所以可能在监听器之间出现，是因为每次调用返回后，控制权短暂回到宿主环境，HTML 的清理机制就可能立刻介入。

不要把“任务边界”当作唯一哨兵。真正需要盯住的是 clean up after running script 和 JS 执行栈是否为空 这两个条件。在宏任务的每一个回调间隙——哪怕是原生事件的两个监听器之间——微任务都可能发动“闪电战”。正是这些隐藏的真空地带，构成了事件循环最精密、也最容易被误判的异步肌理。

5.2 微任务的来源

能够直接进入微任务机制的来源，主要可以理解为以下几个正经来源：

•Promise ： 这是日常开发中最核心的微任务源。ECMAScript 规范把 Promise 的 then、catch、finally 这类后续动作包装成作业（Job），并通过 HostEnqueuePromiseJob 机制交给宿主环境。规范要求这些作业按调度顺序执行，在 Web 平台上，它们会被宿主归入微任务处理流程中。它们不是“立即执行”，也不是“丢进宏任务排队”，而是被放入微任务语境中等待清算。

•queueMicrotask() 的显式接入： 这是 HTML 标准专门提供给开发者的显式人口。它的目的非常直接：允许你安排一个回调挂到微任务队列上，并在当前同步 JavaScript 全部跑完、执行栈下一次清空时尽快运行。它唯一的职责就是向微任务队列投递条目，由于它不会像 setTimeout(fn, 0) 或者是 postMessage 那样切换、让出控制权给新的任务，因此具有极高的时效性。

•MutationObserver 的批量记账机制： 专门用于监听 DOM 树的结构变动。DOM 标准为它准备了 mutation observer microtask queued 这个内部布尔标志位和 pending mutation observers 集合。当 DOM 变动需要通知观察者时，规范会先把变动记录进记录队列，再派发（queue）一个微任务去统一通知这些观察者。也就是说，它不是每改一次 DOM 就立刻跑一次回调，而是先批量记账，再在微任务阶段统一发通知，以此换取极高的布局重绘性能。

•自定义元素生命周期Interaction（Custom Elements Specification）： 这是一个不常被提起的补充点。HTML 的自定义元素规范中明确提到，即使工作发生在构造函数启动的微任务里，微任务检查点也可能在构造完成后立刻发生。这进一步证明了微任务并不只是“回调之后的附属机制”，它还会深度参与并影响更底层的 DOM 构造与生命周期的时序判定。

在日常开发中，我们常常需要延后某些代码的执行。理解了任务与微任务的边界后，我们就对 queueMicrotask() 与 setTimeout(0) 有了比较深入的了解：

•setTimeout(fn, 0) 的本质是申请一个全新的计时器任务。它会强行命令宿主环境的定时器线程去任务队列末尾排队。当它执行时，意味着主线程已经至少经历了一次完整的事件循环轮转，甚至可能已经交出控制权走了一遍重绘视觉管线。它的代价是昂贵的，因为它跨越了任务的边界。

•queueMicrotask(fn) 的本质是在当前任务的内侧边缘疯狂追加。它直接将回调挂载到当前的微任务队列末尾。根据处理模型，它会在当前任务结束、执行栈清空的脚本清理点被直接处决。它绝对不会让出执行权，也绝对不允许浏览器在中间插入任何渲染或别的宏观任务。它是一种纯粹在当前任务时空维度内的“内卷式”延后。

5.3  例子详解

JavaScript

...javascript

// 同一个 DOM 按钮，绑定了 A 和 B 两个完全独立的点击监听器

btn.addEventListener('click', () => {

console.log('监听器 A');

Promise.resolve().then(() => console.log('微任务 A'));

}, false);

btn.addEventListener('click', () => {

console.log('监听器 B');

Promise.resolve().then(() => console.log('微任务 B'));

}, false);

路径 A：原生物理点击（C++ 循环驱动）

当用户的鼠标指针或触控在屏幕上精准命中这个按钮，真实的硬件信号触发了交互任务源。整个事件的分派作为一个独立、干净的任务被推上了主线程：

1.第一步（C++ 掌控全场）： 浏览器底层的 C++ 引擎（Blink）接管主线程，拉开按钮的监听器名册。DOM 标准定义了事件派发会同步遍历监听器列表，C++ 的派发循环（Event Dispatch Loop）迈出第一步。

2.第二步（调用监听器 A）： C++ 引擎跨越底层桥梁，调用绑定的第一个回调。JavaScript 执行上下文栈（Call Stack）推入 Listener A 的栈帧。 当前 JS 执行栈状态： [Listener A] 引擎疯狂输出，控制台打印：'监听器 A'。 遇到 Promise.then，将 微任务 A 挂入微任务队列。

3.第三步（监听器 A 退出，控制权短暂交还）： Listener A 运行完毕，它的函数帧从 JavaScript 执行栈中被彻底弹出。 当前 JS 执行栈状态： []（彻底变为空！）

4.第四步（微任务检查点爆发）： 控制权短暂地回到了 C++ 引擎的手里。在 C++ 迈向下一个监听器之前，HTML 规范的“脚本运行后清理（Clean up after running script）”算法被触发了。算法抬头一看：“当前的 JavaScript 执行栈现在竟然是空的！” 于是，守卫大门打开，微任务检查点开始 C++ 的派发脚步被就地强行挂起，主线程转头去狂扫微任务队列。 控制台输出： '微任务 A'。

5.第五步（调用监听器 B）： 打扫干净战场后，C++ 引擎继续在当前事件派发任务内部推进它的循环，迈向第二站。它调用 Listener B。JavaScript 执行栈再次推入 [Listener B]。 打印：'监听器 B'，产生 微任务 B 并挂入队列。

6.第六步（监听器 B 退出，二次清算）： Listener B 弹出执行栈，JS 栈再次归零（[]）。脚本清理算法第二次检测到栈空，微任务检查点第二次爆发！ 控制台输出： '微任务 B'。

•最终控制台输出顺序： 监听器 A --- 微任务 A --- 监听器 B --- 微任务 B

这叫“打完一架就地分一次战利品”。因为原生事件里控制权在 C++ 宿主与 JS 引擎之间反复横跳，每次监听器返回后，执行栈都已经完全清空。因此，规范完全允许并在机制上决定了原生事件下的多个监听器之间会出现微任务插播。

路径 B：脚本触发 button.click()（JS 同步套娃）

现在，我们将代码场景重置。用户没有点击屏幕，而是在我们一段正在运行的业务脚本 app.js 内部，同步调用了代码：console.log('Before dispatch'); btn.click(); console.log('After dispatch');（或者调用了 dispatchEvent）。

1.第一步（始祖任务压栈）： 事件循环取出执行 app.js 的初始任务。JavaScript 执行栈的底部，压着这段外层脚本的上下文。控制台首先打印：'Before dispatch'。 当前 JS 执行栈状态： [app.js]

2.第二步（遭遇同步激活点）： 代码运行到 btn.click() 这一行。DOM 标准把这类显式 API 激活行为与 click 事件关联起来，明确说明它走的是一条同步激活路径，绝对不会重新开一个新的异步任务去队列排队。 执行栈在不退栈的情况下，直接在顶部追加压入 click 方法的栈帧。 当前 JS 执行栈状态： [app.js, click()]

3.第三步（就地同步调用监听器 A）： 派发引擎直接在当前堆栈的顶部，同步压入第一个监听器的栈帧！ 当前 JS 执行栈状态： [app.js, click(), Listener A] 打印：'监听器 A'，产生 微任务 A 并挂入队列。

4.第四步（监听器 A 退出，守卫拦截）： Listener A 运行完毕弹出执行栈。 当前 JS 执行栈状态： [app.js, click()]（不为空） 此时，同样的脚本运行后清理算法被触发了。但算法一看：“栈还没空呢！外层调用它的 app.js 和 click() 还压在下面呢！” 守卫条件宣告失败，微任务检查点直接被拦截闪避，拒绝执行！ 微任务 A 被卡在队列里不能动。

5.第五步（就地同步调用监听器 B）： 套娃机制推进，引擎在不清理微任务的情况下，继续在栈顶同步压入第二个监听器。 当前 JS 执行栈状态： [app.js, click(), Listener B] 打印：'监听器 B'，产生 微任务 B 并挂入队列。

6.第六步（监听器 B 与派发逻辑退出）： Listener B 弹出，紧接着 click() 方法同步执行完毕也宣告弹出。控制权交还给外层脚本，控制台同步打印：'After dispatch'。 当前 JS 执行栈状态： [app.js]（依然不为空）

7.第七步（最外层宣告落幕，延迟的大清算）： 最终，最外层的 app.js 也终于运行到了最后一行代码，完美弹出执行栈。 当前 JS 执行栈状态： []（经历了漫长的等待，执行栈终于彻底归零！） 在这一瞬间，始祖级任务彻底终结。脚本清理算法终于检测到执行栈回归为空，被压制了整整一力场的微任务检查点在任务结束的边界上爆发，主线程一口气冲进队列，将积压多时的 微任务 A 和 微任务 B 顺次全部处决。

•最终控制台输出顺序： Before dispatch --- 监听器 A --- 监听器 B --- After dispatch --- 微任务 A --- 微任务 B

这叫“必须把整座山头的人都揍完，才能统一分战利品”。因为最外层的主力部队（app.js）还在阵地上压着，主线程判定宏观的任务没有结束，所以中途任何脚本清理点都无法强跑微任务。微任务通常会被整体拖到最外层脚本结束之后的清理阶段统一执行。

两种场景的核心差异对比表

对比维度	场景 1：用户交互触发	场景 2：代码手动触发
触发方式	物理设备输入	JavaScript 代码调用 dispatchEvent
任务类型	独立的宏任务	同步函数调用，无新任务创建
执行栈状态	监听器执行完毕后栈为空	监听器执行完毕后栈仍有外层帧
微任务检查点时机	每个监听器执行完毕后立即触发	整个 dispatchEvent 完成且外层脚本结束后触发
微任务执行时机	穿插在多个监听器之间	所有监听器执行完毕后批量执行
行为一致性	所有浏览器完全一致	所有浏览器完全一致

我们来看一个更复杂的嵌套场景：

...javascript

const button = document.querySelector('button');

// 监听外层事件

button.addEventListener('outer-event', () => {

console.log('Outer Listener');

Promise.resolve().then(() => console.log('Outer Microtask'));

// 在监听器内部同步派发一个不同的事件，以避免死循环。

button.dispatchEvent(new Event('inner-event'));

console.log('After inner dispatch');

});

// 监听内层事件

button.addEventListener('inner-event', () => {

console.log('Inner Listener');

Promise.resolve().then(() => console.log('Inner Microtask'));

});

console.log('Start');

// 派发外层事件，启动嵌套引擎

button.dispatchEvent(new Event('outer-event'));

console.log('End');

输出结果：

...javascript

Start

Outer Listener

Inner Listener

After inner dispatch

End

Outer Microtask

Inner Microtask

步骤解析：

1.console.log('Start') 压栈执行，输出 Start。

2.button.dispatchEvent(new Event('outer-event')) 压栈，同步调用绑定的外层监听器。

3.外层监听器执行，输出 Outer Listener，并将 Outer Microtask 挂入微任务队列。

4.关键点： 执行 button.dispatchEvent(new Event('inner-event'))，派发逻辑直接在当前栈顶继续压入内层监听器。

5.内层监听器执行，输出 Inner Listener，将 Inner Microtask 挂入微任务队列。内层出栈。

6.回到外层监听器，输出 After inner dispatch。外层出栈。

7.最外层脚本继续执行 console.log('End')。

8.整个始祖级脚本终于执行完毕，执行上下文栈（Call Stack）真正被彻底清空。

9.触发 HTML 规范的 Clean up 步骤，闸门打开，积压的微任务依次执行：输出 Outer Microtask 和 Inner Microtask。

通过区分 outer-event 和 inner-event，我们可以得知：无论事件的名字叫什么，只要它们是通过 dispatchEvent 嵌套触发的，它们就共享同一个同步的执行上下文栈，微任务就必须老老实实等到最外层调用结束才能执行。

注意点：

1.错误的观点：不要认为\"事件回调都是宏任务\"。事件本身不是任务，触发事件的方式决定了它是否在一个新任务中执行。

2.嵌套 dispatchEvent 的情况：如果在一个监听器中再次调用 dispatchEvent 触发另一个事件，那么内层事件的所有监听器也会同步执行，微任务会被积压到最外层任务结束。

3.特殊情况：冒泡与捕获阶段：无论事件处于捕获、目标还是冒泡阶段，上述规则都完全适用。微任务检查点只会在每个监听器执行完毕后检查栈是否为空。

微任务在脚本清理步骤中触发，当执行栈为空时就可能执行。任务边界只是最常见的触发点之一。

DOM 事件派发是同步的，但每个监听器返回后，只要栈空，HTML 清理步骤就可能插入微任务检查点。

要注意规范和实现的区别，不同浏览器、不同事件类型和不同回调结构下，微任务插入时机可能存在实现差异，不能简单把某一种表现当成唯一规范结论。

5.4 微任务与渲染：为什么它又快、又危险

微任务的优点是“快”，因为它紧贴着执行栈的尾翼；但它的代价也正是“太快”。

HTML 标准在对 queueMicrotask() 的开发者说明里特别发出了警告：如果你安排了过多的微任务，它们的性能副作用会和编写大量的同步代码高度相似，都会阻止浏览器去做自己的工作。

这涉及到微任务与浏览器渲染管线（Update the rendering）的优先级博弈。在事件循环的处理模型中，微任务清算的优先级是高于视觉渲染的。这意味着，微任务是“不让出控制权的前提下，尽快完成收尾”。

如果你的目标只是“在下一次屏幕刷新重绘前运行一些代码”，微任务绝对不是合适的工具，因为微任务会在渲染机会评估之前被强行全部处决；此时，requestAnimationFrame() 才是更契合视觉管线周期的天然拦截器。微任务在设计上应当专注于做“收口型工作”，而不适合做“长链路计算”。

所以，微任务的完美适用场景： 把同一轮同步执行里产生的多笔状态变化进行合并（批处理）、在 DOM 变动后统一读写以防频繁重排、在 Promise 链的尾部做统一的异常收束逻辑。

6.异步

在经历了前面对任务（Task）与微任务（Microtask）的深入了解以后，我们终于来到了整个 JavaScript 运行时中，最容易让人产生时空错觉的认知转折点——异步（Asynchrony）。

很多初学者常常将“异步”挂在嘴边，在他们的脑海深处，似乎有个幻觉：当代码执行到异步操作时，主线程里仿佛突然撕裂开了一个平行宇宙，或者分身出了一个新的小弟，在后台默默地帮他搬砖。

我们打碎这个幻觉，真正认识异步。

6.1 单线程的并发

要学透异步，首先必须在学术和工程层面上，理解两个底层概念——并行（Parallelism）与并发（Concurrency）。

•并行（Parallelism）： 指的是在同一个绝对时间点上，有多颗 CPU 核心在物理上同时执行多段不同的代码。这需要真正的硬件“分身术”。

•并发（Concurrency）： 指的是在一段宏观的时间周期内，程序通过极其高频的切换调度，让多段任务交替执行，从而在宏观上伪造出一种“多件事情同时在运行”的丝滑幻觉。

JavaScript 的主线程，是典型的单线程协作式并发。

在 V8 引擎的真实世界里，主线程从来没有分身术。如果有一步操作需要发起网络请求去获取一个 10MB 的大文件，或者去等待磁盘读取一块厚重的数据，在以前的同步阻塞思维里，主线程就必须在原地干等着。此时，整个执行上下文栈死死卡住，程序停摆，这就是“阻塞（Blocking）”。

而异步则不同，主线程引擎一看，这个网络响应或定时器到期不知道要等到猴年马月，在原地干等就是对 CPU 算力的犯罪。于是，它运用了时间维度的拆分策略：把当下不能立刻完成、或者代价极其高昂的活儿，先在宿主环境的通讯录上登记下来，接着立刻把当前的主线程执行权让出来，去跑后面能跑的同步代码。

异步的精髓绝不是“在物理上同时干两件事”，而是“发起登记 --- 移交控制权 --- 后台等待 --- 未来触发”。它保证了单线程永远在做有意义的运算，而不是死等。