Event Loop 不是 V8 的一部分，而是由宿主环境（浏览器/Node.js）提供和驱动；V8 仅负责编译、执行与内存管理，任务调度、队列维护及宏/微任务分发均由宿主控制。
Event Loop 不是 V8 引擎的一部分，它由宿主环境（如浏览器或 Node.js）提供和驱动。V8 只负责 JavaScript 代码的编译、执行和内存管理；Event Loop 的调度、任务队列维护、宏/微任务分发等行为，均由外部运行时控制。
V8 初始化阶段：Event Loop 尚未启动
当浏览器打开一个标签页或 Node.js 启动进程时，渲染进程（浏览器）或主线程（Node.js）会先初始化宿主环境，再创建 V8 实例。此时 V8 仅完成自身结构（堆、栈、上下文、Ignition/TurboFan 等）的分配与配置，但Event Loop 还未开始循环。它会在脚本首次执行完毕、且存在待处理异步任务（如 setTimeout、Promise 回调）后，才进入第一个 tick。
- 同步脚本（如
console.log("start")）直接在主线程执行，不依赖 Event Loop - V8 此时只做解析（Scanner → Parser → AST → Ignition 字节码）、执行和堆内存分配
- 所有 Web API（如
setTimeout、fetch）调用，实际由浏览器线程注册并延迟加入任务队列，V8 不参与调度
脚本加载与执行阶段：Event Loop 开始运转
一旦初始脚本执行结束，宿主环境立即检查任务队列：若有宏任务（如 DOM 事件、定时器回调、I/O 完成通知），Event Loop 启动循环；每个宏任务执行前，会先清空当前轮次的所有微任务（如 Promise.then、queueMicrotask）。
- V8 在该阶段持续工作：解释字节码、JIT 编译热点函数、维护调用栈与堆对象引用
- 微任务队列由宿主在每次宏任务结束后主动清空，V8 仅提供
Promise构造和then注册的底层能力，不决定执行时机 - 例如：
setTimeout(() => console.log(1), 0); Promise.resolve().then(() => console.log(2))中，2 总是先于 1 输出——这是宿主 Event Loop 的规则，不是 V8 决定的
垃圾回收阶段：Event Loop 暂停让出 CPU，但不中断逻辑状态
V8 的垃圾回收（GC）发生在主线程，会暂停 JavaScript 执行（stop-the-world）。此时 Event Loop 也暂停推进新任务，但已入队的宏/微任务仍保留在各自队列中，等待 GC 结束后继续调度。
立即学习“Java免费学习笔记（深入）”；
- 新生代 Scavenge 回收快（毫秒级），对 Event Loop 影响小；老生代 Mark-Sweep/Compact 耗时更长，可能导致明显卡顿
- GC 不改变任务队列顺序或状态，只是“延后执行”，而非丢弃或重排任务
- V8 会根据内存压力自动触发 GC，也可通过
gc()（仅调试模式启用）手动触发，但宿主不会因此跳过下一个宏任务
Event Loop 和 V8 是协作关系：V8 提供执行能力，宿主提供调度框架。理解这一点，就能避免把异步行为归因于引擎本身——真正决定“何时执行回调”的，永远是浏览器或 Node.js 的运行时机制。
