> 浏览器渲染原理是非常常见的面试问题，那么你真的了解它吗，或者说，浏览器渲染原理你可以利用起来吗。感谢之前字节的面试官，问了我一帧的流程包括哪些，我收集了一些资料，简单整理如下，之后有空再补充补充。



本文还参考了如下翻译版本：[gold-miner/TODO1/the-anatomy-of-a-frame.md at master · xitu/gold-miner · GitHub](https://github.com/xitu/gold-miner/blob/master/TODO1/the-anatomy-of-a-frame.md)

浏览器一帧渲染包括如下流程：

![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/1d4688314f73545ea737ddbc1a5ba169.png)

**参与的进程包括**
- 渲染进程（Renderer Process）：**它是标签页的容器。包含多个线程，负责页面渲染的各个阶段**。这些线程分别是：合成器线程(Compositor Thread) 、 图块工作线程(Compositor Tile Worker)和主线程(Main Thread)
- GPU 进程（GPU Process）：**这是服务于所有标签页和相关浏览器进程的单一进程**。提交帧时，GPU 进程会将所有图块和其他数据（例如四边形顶点和矩阵）上传到 GPU，以便将像素实际推送到屏幕。GPU 进程包含一个称为 GPU 线程的单线程，负责实际执行工作。

**渲染进程中的线程**
> 在很多方面，你可以把合成线程（Compositor Thread）看作是“总指挥”。虽然它本身不负责运行 JavaScript、布局（Layout）、绘制（Paint）等任务，但它完全负责启动主线程的相关工作，并最终将渲染好的帧展示到屏幕上。

- **合成线程**（Compositor Thread）。这是第一个接收到 `vsync` 事件的线程（`vsync` 事件是操作系统通知浏览器生成新帧的方式）。它还会接收所有输入事件。合成线程会尽量避免将任务交给主线程，而是尝试直接将输入（比如滚动的快速滑动）转换为屏幕上的移动。它通过更新图层的位置，并通过 GPU 线程将帧提交给 GPU 来实现这一点。如果由于存在输入事件处理器或其他视觉相关的工作而无法这样做，就需要主线程参与处理。
- **主线程**（Main Thread）。这是浏览器执行我们熟悉和喜爱的各种任务的地方：JavaScript、样式、布局和绘制。（未来在 Houdini 的支持下，这种情况会有所改变，届时我们可以在合成线程中运行部分代码。）由于主线程上运行的内容非常多，它也最容易引发页面卡顿，因此可以说它“最有可能导致卡顿”。
- **合成图块工作线程**（Compositor Tile Worker(s)）。这是由合成线程创建的一个或多个工作线程，用于处理光栅化（Rasterization）任务。稍后我们会进一步介绍这一点。

**流程概述**
![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/c2010da7d8bb7c0e5889634f978e707f.png)
1. **帧开始**（Frame Start）：Vsync 事件被触发，帧开始。
2. **输入事件处理**（Input event handlers）：输入数据从合成线程传递到主线程的所有输入事件处理器。所有输入事件处理器（如 `touchmove`、`scroll`、`click`）应该在每帧最先触发，但实际情况不一定总是如此；调度器会尽力安排，成功率在不同操作系统间有所不同。从用户交互到事件被主线程处理，中间还存在一定延迟。
3. `requestAnimationFrame`：这是进行视觉更新的理想时机，因为你拥有最新的输入数据，并且这是最接近 vsync 的时刻。其他视觉任务，如样式计算，会在此任务之后进行，所以此时变更元素最为合适。如果你一次性变更了 100 个 class，不会导致 100 次样式计算；这些变更会被批量处理。唯一需要注意的是，不要在这时查询任何计算样式或布局属性（如 el.style.backgroundImage 或 el.style.offsetWidth）。如果这么做，会提前触发样式重计算、布局或两者，导致强制同步布局，甚至更糟的布局抖动。
4. **解析 HTML**（Parse HTML）：处理新添加的 HTML，并创建 DOM 元素。页面加载期间或执行 appendChild 等操作后，这一步会频繁出现。
5. **样式重计算**（Recalc Styles）：为新添加或变更的内容计算样式。可能影响整个 DOM 树，也可能仅限于部分区域，取决于变更内容。例如，修改 body 的 class 影响范围很大，但值得注意的是浏览器会自动智能地缩小样式计算的范围。
6. **布局**（Layout）：为每个可见元素计算几何信息（位置和尺寸）。通常针对整个文档进行，计算量与 DOM 大小成正比。
7. **更新 Layer树**（Update Layer Tree）：创建堆叠上下文并对元素进行深度排序的过程。
8. **绘制**（Paint）：这是一个两步过程的第一步：绘制是为所有新出现或发生视觉变化的元素记录绘制指令（比如在这里填充矩形、在那里写文本）。第二步是光栅化（见下文），即执行绘制指令并填充纹理。绘制指令的记录通常比光栅化快很多，但这两个步骤通常统称为“绘制”。
9. **合成**（Composite）：计算层和瓦片信息，并将其传递回合成线程进行处理。这一步会处理 `will-change`、重叠元素以及所有硬件加速的 canvas 等内容。
10. **光栅化调度与光栅化**（Raster Scheduled and Rasterize）：在绘制任务中记录的绘制指令现在被执行。这一步由合成瓦片工作线程（Compositor Tile Workers）完成，线程数量取决于平台和设备能力。例如，Android 通常只有一个工作线程，桌面端有时可以有四个。光栅化是以层为单位进行的，每个层由多个瓦片组成。
11. **帧结束**（Frame End）：各层的所有瓦片光栅化完成 后，任何新瓦片以及输入数据（可能已在事件处理器中发生变化）被提交到 GPU 线程。
12. **帧提交**（Frame Ships）：最后但同样重要的是，GPU 线程将瓦片上传到 GPU。GPU 利用四边形和矩阵（所有常见的 GL 技术）将瓦片绘制到屏幕上。
13. **附加环节**：如果主线程在一帧结束时还有空闲时间，则会触发 `requestIdleCallback`。这是执行非关键性任务（如发送分析数据）的绝佳时机。

**渲染流程中的层层叠加**：包括两个阶段
1. 首先是“堆叠上下文”（Stacking Contexts），比如有两个绝对定位且重叠的 div。Update Layer Tree 阶段会确保 z-index 等属性被正确处理。
2. 其次是“合成层”（Compositor Layers），这发生在流程稍后的阶段，主要用于已绘制元素的管理。可以通过 null transform hack 或 will-change: transform 将元素提升为合成层，这样可以低成本地进行变换（适合动画）。不过，如果有重叠元素，为了保持 z-index 等属性指定的深度顺序，浏览器也可能需要创建额外的合成层。

**CPU 和 GPU**
- 上述流程几乎全部在 CPU 上完成。只有最后一部分——**图块的上传和移动**——是在 GPU 上完成的。
- 但在 Android 上，像素流在光栅化阶段有所不同：GPU 的使用更多。此时，不是由合成瓦片工作线程进行光栅化，而是**将绘制指令作为 GL 命令在 GPU 的着色器中执行**。
- 这被称为 **GPU 光栅化**（GPU Rasterization），是降低绘制成本的一种方式。你可以通过在 Chrome DevTools 中启用 `FPS Meter` 来判断页面是否启用了 GPU 光栅化。

相关文档
- 帧的生命周期 (看不懂)： https://chromium.googlesource.com/chromium/src/+/112.0.5615.165/docs/life_of_a_frame.md
- 一帧的构成 (这篇博客很不错): https://aerotwist.com/blog/the-anatomy-of-a-frame/
- Mozilla 图解浏览器渲染 (还不错): https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/
- RAIL 模型评估性能(先收藏了)： https://web.dev/articles/rail?hl=zh-cn
- requestAnimationFrame 和性能优化(先收藏了)： https://web.dev/articles/optimize-javascript-execution?hl=zh-cn
- 关键渲染路径 (看不懂)： https://web.dev/articles/critical-rendering-path?hl=zh-cn
- 深入了解现代浏览器 (先收藏了): https://developer.chrome.com/blog/inside-browser-part1?hl=zh-cn
- 像素的生命周期 (渡一所谓浏览器渲染原理大师课抄的课件): https://docs.google.com/presentation/d/1boPxbgNrTU0ddsc144rcXayGA_WF53k96imRH8Mp34Y/
- HTML 规范中事件循环部分 (看不懂): https://html.spec.whatwg.org/multipage/webappapis.html#event-loop

浅谈浏览器渲染-面试常考

> 本文为作者在团子写的一个小的开发体验优化需求，截取片段



# 1 背景与目标

## 1.1 背景

商户服务需要对外提供 h5 / pc 等多种形态的页面，对应页面为 /pc.html 、/h5.html 等，但目前 yarn serve 时只会干巴巴的展示 [127.0.0.1:8080](http://127.0.0.1:8080/)，点击了又访问不了；同时页面访问时可能需要若干 query 参数，需要手动拼接等，影响开发体验。

目前有些服务需要口口相传、手动拼接；account 仓库也有不同方案，心智不统一：

1. xx1 packages/xx1 ，放在 readme
2. xx2 packages/xx2，根目录也会作为开发引导，暂时可开发访问的链接
3. xx3 packages/xx3，需访问 127.0.0.1:8080/dev.html（根路径会作为 pc/h5 自适应的地址）
## 1.2 目标

yarn serve 执行成功后直接输出可访问的地址，如 127.0.0.1:8080/dev.html 等，快速进入开发阶段。

# 2 整体方案

## 2.1 如何去指明开发入口

| 方案 | 说明 | 选择 | 备注 |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- | --- |
| 方案一：维护一个readme | 在每个服务下维护一个readme，作为文档及指导开发方式（比如入口在哪，需要怎么配置） 并且作为开发者，会自然的查看仓库下的readme，readme传递的信息比较丰富且有效。 | | |
| 方案二：对vue-cli打印的日志进行修改 | 在vue-cli的devServer打印的日志上做修改，修改running at的url或者在其之前之后打印一些提示信息 ![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/4e30bbb08d6bde9a54ccc9352d57a2fb.png) 打印日志的方式最为直接且方便，但是在实际项目中，打印的日志信息很可能被覆盖，对url的修改可能有侵入性，对代码维护可能不友好。 | | |
| 方案三：自动打开浏览器并指向对应的开发入口 | 不做提示，只通过devServer的打开浏览器操作打开到正确的路径。![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/a2fd6faedf94f8482d5ed40df15b494d.png) 修改量最小，也能有效的引导到正确的路径，但是缺乏信息。 | | |

**综合考虑，可以选择方案二。**

## 2.2 怎么在控制台打印入口

在上述整体方案选择为方案二的同时，方案二也有几种实现方法

| 方案 | 说明 | 选择 | 备注 |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --- | --- |
| 实现一：在vue-cli输出之下添加自行拼接的url | ![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/a93d5dbb7d125b52cec1d7d2fd7a062f.png) 通过获取开发服务器的协议(http/https)、host、端口、publicPath，并拼接上开发入口的路径，形成最终完整的路径。 | | |
| 实现二：使用子父进程监听vue-cli的输出并修改 | 通过正则匹配到了url位置，但是其他的输出内容也有变化，比如颜色显示没有了。而且使用父进程控制`yarn serve`也可能引起一些未知的问题，在这里不推荐。 | | |

## 2.3 如何实现

> **背景说明：**
> `@mtfe/mwallet-build` 是团队中构建配置的 `npm` 包，提供 Webpack 的诸多配置，其中 `handleDevServer` 为开发服务器的配置文件，配置了 Mock 代理、或者泳道代理等等

在启动开发服务器时打印信息，本质利用的是 Webpack 的 `完成时` 生命周期，使用 `compiler.hooks.done` 即可注册一个钩子，每当服务器启动时，或者热更新时，会触发钩子执行。

在生命周期操作，正常是需要使用插件实现的，本着最小改造量的目的，想到 `devServer` 的 `before` 和 `after` （**只在 webpack4中有效，webpack5中需要使用 `setupMiddlewares` 替代**）也可以获取到 `compiler对象进行操作`

**通过修改devServer在webpack dev server的各个时期去获取url的部分，并最终拼接成为开发入口，即可达到本次改造的目标**。


1. **获取URL**
URL由protocol、host、port和publicPath组成，其中只有port是非指定的，可以是自动寻找的端口
因此获取port稍微复杂，查询webpack dev server的文档可以知道通过onListening函数拿到server实例
就可以获取 port（也仅为 webapck4 ），最终拼接 url 即可。

1. **在 vue-cli 打印的信息之后打印 URL 并且在热更新时也打印**
compiler下的 done hook 回调，可以实现在每次编译完成之后执行一段函数，就可以在这个函数中打印URL。
整体流程如下，在webpack dev server生命周期的各个部分，可以拿到不同的数据，最终拼接url。

![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/1ca2b28f8ff79159b24e36b498751343.png)

注：本需求仅适配 webpack4

## 2.4 Webpack5的方法

`before` 注册钩子和 `onListening` 获取端口仅在 `Webpack4` 生效，`Webpack5` 可以参考下面方法

```js
module.exports = defineConfig({
	transpileDependencies: true,
	configureWebpack: {
		devServer: {
			port: 7890,
			setupMiddlewares(middlewares, devServer) {
				if (!devServer) {
					throw new Error("webpack-dev-server is not defined");
				}

				devServer.compiler.hooks.done.tap("printEntry", () => {
					console.log("编译完成", devServer.compiler.options.devServer?.port ?? 8080);
				});
				return middlewares;
			},
		},
	},
});
```

# 3. 拓展

## 3.1 Vite 生命周期和钩子

| 阶段 | 钩子名称 | 类型 | 触发时机 | 参数 |
| --------- | -------------------- | ----- | --------------------------- | ----------------------------- |
| 配置阶段 | `config` | 同步/异步 | 在 Vite 配置加载之前 | `(config, { command, mode })` |
| | `configResolved` | 同步 | 配置解析完成后 | `(resolvedConfig)` |
| 优化阶段 | `buildStart` | 同步/异步 | 构建开始时 | `()` |
| | `resolveId` | 同步/异步 | 模块解析时 | `(source, importer, options)` |
| | `load` | 同步/异步 | 模块加载时 | `(id)` |
| | `transform` | 同步/异步 | 模块转换时，如编译 TypeScript、处理 JSX | `(code, id)` |
| | `handleHotUpdate` | 异步 | 处理热更新（HMR）时 | `({ file, server, modules })` |
| 开发服务器阶段 | `configureServer` | 异步 | 配置开发服务器时，添加中间件或路由 | `(server)` |
| HTML 转换阶段 | `transformIndexHtml` | 同步/异步 | 转换 `index.html` 时，修改或注入内容 | `(html, ctx)` |
| 构建阶段 | `generateBundle` | 同步/异步 | 生成最终包之前 | `(options, bundle, isWrite)` |
| | `writeBundle` | 同步/异步 | 所有文件写入磁盘后 | `()` |
| | `closeBundle` | 同步/异步 | 构建完成后，适合做清理工作 | `()` |
## 3.2 Webpack 生命周期和钩子

| 阶段 | 钩子名称 | 类型 | 触发时机 | 参数 |
| ----- | ------------------- | --- | ----------------------- | ---------------------------------- |
| 初始化阶段 | `environment` | 同步 | 准备编译环境时 | - |
| | `afterEnvironment` | 同步 | 环境准备完成后 | - |
| | `entryOption` | 同步 | entry 配置项处理后 | `(context, entry)` |
| | `afterPlugins` | 同步 | 插件注册完成后 | `(compiler)` |
| | `afterResolvers` | 同步 | resolver 安装完成后 | `(compiler)` |
| 编译阶段 | `beforeRun` | 异步 | 开始正式编译前 | `(compiler)` |
| | `run` | 异步 | 开始编译时 | `(compiler)` |
| | `watchRun` | 异步 | 监听模式下，开始编译时 | `(compiler)` |
| | `beforeCompile` | 异步 | compilation 参数创建后 | `(compilationParams)` |
| | `compile` | 同步 | 一次 compilation 创建前 | `(compilationParams)` |
| | `compilation` | 同步 | compilation 创建后 | `(compilation, compilationParams)` |
| | `make` | 异步 | 从 entry 开始递归分析依赖时 | `(compilation)` |
| 构建阶段 | `afterCompile` | 异步 | 完成构建、封存完成后 | `(compilation)` |
| | `shouldEmit` | 同步 | 是否输出文件 | `(compilation)` |
| | `emit` | 异步 | 输出 assets 到 output 目录之前 | `(compilation)` |
| | `afterEmit` | 异步 | 输出 assets 到 output 目录之后 | `(compilation)` |
| 完成阶段 | `done` | 同步 | 编译完成 | `(stats)` |
| | `failed` | 同步 | 编译失败 | `(error)` |
| 监听相关 | `watchClose` | 同步 | 监听模式停止 | - |
| | `infrastructureLog` | 同步 | 日志输出时 | `(name, type, args)` |
**补充说明：**
1. 钩子类型:
2. 同步钩子：使用 tap() 方法注册
3. 异步钩子：可使用 tapAsync () 或 tapPromise () 方法注册

## 3.3 Vite 如何实现

```js
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

function PreStartLoggerPlugin() {
	return {
		name: "pre-start-logger",
		config() {
			console.log("🔧 准备启动 Vite 开发服务器...");
		},
		configResolved(config) {
			console.log(`🛠 当前工作目录: ${config.root}`);
			console.log(`📂 输出目录: ${config.build.outDir}`);
		},
		configureServer(server) {
			server.httpServer?.once("listening", () => {
				const address = server.httpServer?.address();
				if (address && typeof address === "object") {
					console.log(
						`🚀 开发服务器已启动，访问地址: http://localhost:${address.port}`
					);
				}
			});
		},
	};
}

// https://vite.dev/config/
export default defineConfig({
 plugins: [vue(),PreStartLoggerPlugin()],
})
```

![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/5508641ce133419b2b999f4bb903a498.png)

## 3.4 Webpack 插件实现打印

```js
const { defineConfig } = require("@vue/cli-service");

class PreStartLoggerPlugin {
	apply(compiler) {
		compiler.hooks.watchRun.tap("PreStartLoggerPlugin", (compiler) => {
			console.log("🔧 准备启动 Webpack 开发服务器...");
			console.log(`🛠 当前工作目录: ${process.cwd()}`);
			console.log(`📂 输出目录: ${compiler.options.output.path}`);
		});
 // 主要依靠这个hook实现打印效果
		compiler.hooks.done.tap("PreStartLoggerPlugin", (stats) => {
			const devServer = compiler.options.devServer;
			const port = devServer?.port || 8080;
			console.log(`🚀 开发服务器已启动，访问地址: http://localhost:${port}`);
		});
	}
}

module.exports = defineConfig({
	transpileDependencies: true,
	configureWebpack: {
		plugins: [new PreStartLoggerPlugin()],
 devServer: {
 port: 7890
 }
	},
});
```

为Webpack添加启动开发服务器提示

> 最近面试时总被问到一些如为什么Vite比Webpack快、ESM和CJS的对比、Tree Shaking的原理等等的面试题，大多数时候我只能凭感觉简单说道几句，给面试官的印象就是，不太懂这些，基础不牢，于是我查阅诸多资料，总结了前端工程化的起始发展和目前的常用的一些技术原理概述。



## 1.前端工程化概述

**我们可以使用HTML、CSS、JavaScript编写网站，为什么需要工程化？**

大型项目的几个痛点

1. 需要区分各种代码环境，如开发环境、生产环境等等
2. 对于图片、CSS、字体、第三方库等资源需要规范的管理
3. 代码中使用了JS新特性或者CSS新特性但是需要向下兼容老设备或者其他浏览器
4. 使用其他语言如TS、JSX，使用预处理器增强CSS等
5. 发布时对于未使用的代码，将其剔除(Tree-shaking)，并对最终的代码进行代码压缩(Tensor)

如果是在普通的项目中，对于上面这些特性需要配置复杂的环境，且难以做到统一标准，维护代码相当麻烦

于是出现了诸如Webpack、Vite一类的工程化工具。

本文不讨论实际的配置和代码，主要讲述工程化中的一些概念，帮助更好理解前端工程化。

## 2.模块化

自 2009 年 Node.js 诞生，前端先后出现了 `CommonJS`、`AMD`、`CMD`、`UMD`和`ES Module` 等模块规范。

### 无模块化标准阶段

早在模块化标准还没有诞生的时候，前端界已经产生了一些模块化的开发手段，如`文件划分`、`命名空间`和 `IIFE 私有作用域`。



### CommonJS

CommonJS 是业界最早正式提出的 JavaScript 模块规范，主要用于服务端，随着 Node.js 越来越普及，这个规范也被业界广泛应用。对于模块规范而言，一般会包含 2 方面内容:

- 统一的模块化代码规范

- 实现自动加载模块的加载器(也称`loader`)

代码中使用 `require` 来导入一个模块，用`module.exports`来导出一个模块。实际上 Node.js 内部会有相应的 loader 转译模块代码，最后模块代码会被处理成下面这样:

```ts
(function (exports, require, module, __filename, __dirname) {
 // 执行模块代码
 // 返回 exports 对象
});
```



### AMD

`AMD`全称为`Asynchronous Module Definition`，即异步模块定义规范。模块根据这个规范，在浏览器环境中会被异步加载，而不会像 CommonJS 规范进行同步加载，也就不会产生同步请求导致的浏览器解析过程阻塞的问题了。我们先来看看这个模块规范是如何来使用的:

```js
// main.js
define(["./print"], function (printModule) {
 printModule.print("main");
});

// print.js
define(function () {
 return {
 print: function (msg) {
 console.log("print " + msg);
 },
 };
});
```

由于没有得到浏览器的原生支持，AMD 规范需要由第三方的 loader 来实现，最经典的就是 [requireJS](https://github.com/requirejs/requirejs) 库了，它完整实现了 AMD 规范，至今仍然有不少项目在使用。



### ES Module

`ES6 Module` 也被称作 `ES Module`(或 `ESM`)， 是由 ECMAScript 官方提出的模块化规范，作为一个官方提出的规范，`ES Module` 已经得到了现代浏览器的内置支持。在现代浏览器中，如果在 HTML 中加入含有`type="module"`属性的 script 标签，那么浏览器会按照 ES Module 规范来进行依赖加载和模块解析，这也是 Vite 在开发阶段实现 no-bundle 的原因，由于模块加载的任务交给了浏览器，即使不打包也可以顺利运行模块代码。



### 几种模块化规范的对比

| 运行环境 | 加载方式 | 运行机制 | 特点 | |
| ------------- | -------- | -------- | ------------------------------------------------------ | -------- |
| 服务器 | 同步 | 运行时 | 第一次加载后会将结果缓存，再次加载会读取缓存的结构。 | CommonJS |
| 浏览器 | 异步 | 运行时 | 依赖前置，不管模块是否有用到，都会全量加载。 | AMD |
| 浏览器 | 异步 | 运行时 | 依赖就近，延迟加载 | CMD |
| 浏览器/服务端 | 异步 | 编译时 | 静态化，在编译时就确定模块之间的依赖关系，输入和输出。 | ESM |



### 为什么Tree Shaking只能在ESM上使用

不同于其他几种标准，ESM加载模块是静态的，在编译时就确定了模块于模块的关系，在使用一些打包器如Webpack时，他会分析依赖图从而删除一些未使用的模块和代码，保证打包结果的轻量。像CommonJS这类，是动态加载的，无法确定依赖图，从而无法进行Tree Shaking。

## 3.Webpack

### 3.1 Webpack是什么

Webpack 是一种用于构建 JavaScript 应用程序的静态模块打包器，它能够以一种相对一致且开放的处理方式，加载应用中的所有资源文件（图片、CSS、视频、字体文件等），并将其合并打包成浏览器兼容的 Web 资源文件。

它会在内部从一个或多个入口点构建一个 [依赖图(dependency graph)](https://webpack.docschina.org/concepts/dependency-graph/)，然后将你项目中所需的每一个模块组合成一个或多个 *bundles*，它们均为静态资源，用于展示你的内容。

![image.png](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/8fadfbba30a303625613adfd6cb88a7d.png)



### 3.2 Webpack中的一些概念

#### entry

**入口起点(entry point)** 指示 webpack 应该使用哪个模块，来作为构建其内部 [依赖图(dependency graph)](https://webpack.docschina.org/concepts/dependency-graph/) 的开始。进入入口起点后，webpack 会找出有哪些模块和库是入口起点（直接和间接）依赖的。



#### output

**output** 属性告诉 webpack 在哪里输出它所创建的 *bundle*，以及如何命名这些文件。主要输出文件的默认值是 `./dist/main.js`，其他生成文件默认放置在 `./dist` 文件夹中。



#### dependency graph

每当一个文件依赖另一个文件时，webpack 都会将文件视为直接存在 *依赖关系*。这使得 webpack 可以获取非代码资源，如 images 或 web 字体等。并会把它们作为 *依赖* 提供给应用程序。

当 webpack 处理应用程序时，它会根据命令行参数中或配置文件中定义的模块列表开始处理。 从 [*入口*](https://webpack.docschina.org/concepts/entry-points/) 开始，webpack 会递归的构建一个 *依赖关系图*，这个依赖图包含着应用程序中所需的每个模块，然后将所有模块打包为少量的 *bundle* —— 通常只有一个 —— 可由浏览器加载。



#### Chunk

Webpack在生成依赖图后，遍历Entry对象，创建中间产物Chunk，并根据Chunk生成最终的bundle



#### bundle

bundle 是 Webpack 打包后的最终输出文件。它包含了经过处理和优化的项目代码、依赖库以及各种资源。



#### sourcemap

[Sourcemap 协议](https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit#heading=h.qz3o9nc69um5) 最初由 Google 设计并率先在 Closure Inspector 实现，它的主要作用就是将经过压缩、混淆、合并的产物代码还原回未打包的原始形态，帮助开发者在生产环境中精确定位问题发生的行列位置



#### loader

webpack 只能理解 JavaScript 和 JSON 文件，这是 webpack 开箱可用的自带能力。**loader** 让 webpack 能够去处理其他类型的文件，并将它们转换为有效 [模块](https://webpack.docschina.org/concepts/modules)，以供应用程序使用，以及被添加到依赖图中。



#### plugin

Plugin 是用于扩展 Webpack 功能的插件，可以在 Webpack 构建过程的不同阶段执行各种任务。Plugin 可以实现更复杂的功能，如代码压缩、优化、生成 HTML 文件、清理输出目录等。



#### Mode

通过选择 `development`, `production` 或 `none` 之中的一个，来设置 `mode` 参数，你可以启用 webpack 内置在相应环境下的优化。其默认值为 `production`。



### 3.3 Webpack的开发时和打包时

**开发时**

使用Webpack开发web应用时，启动开发服务器需要递归打包整个依赖树，然后将打包结果缓存到本地，供下次修改代码后快速更新，又因为Webpack使用JavaScript编写性能较弱，所以Webpack开发服务器的启动速度很慢。

**打包时**

Webpack的流程一般是，入口分析识别模块引用，遍历模块生成依赖图，根据遍历的结果使用相应的loader进行构建处理，同时也会在不同阶段运行plugin处理中间产物，最后生成产物。



### 3.4 Webpack的优化手段

#### 持久化缓存

webpack5引入了持久化缓存特性，将首次构建的过程与结果数据持久化保存到本地文件系统，在下次执行构建时跳过解析、链接、编译等一系列非常消耗性能的操作，直接复用上次的 Module/ModuleGraph/Chunk 对象数据，迅速构建出最终产物。



#### 动态加载

动态加载是 Webpack 内置能力之一，我们不需要做任何额外配置就可以通过动态导入语句$`import`、`require.ensure`$轻易实现。但请 注意，这一特性有时候反而会带来一些新的性能问题：**一是过度使用会使产物变得过度细碎，产物文件过多，运行时 HTTP 通讯次数也会变多**，在 HTTP 1.x 环境下这可能反而会降低网络性能，得不偿失；**二是使用时 Webpack 需要在客户端注入一大段用于支持动态加载特性的 Runtime**。



#### HTTP 缓存优化

通过给生成产物文件名加上一段由产物内容生成的Hash值，对所有产物设置强缓存，当内容更新时，文件名的Hash值改变，引起服务器重新加载新的产物文件。



#### 使用外置依赖

 使用 Webpack 的 `externals` 特性将部分模块排除在 Webpack 打包系统之外，然后可以使用CDN的方式引入，Webpack 会 **预设** 运行环境中已经内置这些库。



#### 使用Tree-shaking删除多余模块导出

Tree-Shaking 较早前由 [Rich Harris](https://github.com/Rich-Harris) 在 Rollup 中率先实现，Webpack 自 2.0 版本开始接入，是一种基于 ES Module 规范的 Dead Code Elimination 技术，它会在运行过程中静态分析模块之间的导入导出，判断哪些模块导出值没有被其它模块使用 —— 相当于模块层面的 Dead Code，并将其删除。

## 4.Vite

### 4.1 Vite是什么

Vite和Webpack类似，都是一种打包器，Vite一般可用于Web应用的开发，得益于其中内置的ESBuild和Rollup，Vite在开发和打包时的体验都相当好。值得注意的是ESBuild使用GO语言编写因此拥有非常快的速度，而Rollup使用JavaScript编写的。

![image.png](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/15933861023848f895fab37ad99de1e4.png)



### 4.2 Vite 中的一些概念

#### 4.2.1 开发时

##### no-bundle

no-bundle是vite重要的概念，vite的开发服务器借助浏览器支持ESM的性质，对于项目的源码不进行打包(no-bundle)，只对第三方库进行打包(兼容ESM格式和解决递归依赖加载问题)。

可以说no-bundle是vite启动快的重要原因。

##### 预构建

![image.png](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/c99ccaa30ec4469bc5d0fc981377d417.png)

在启动开发服务器之前会先进行预构建，会将第三方依赖打包并转换为ESM（主要是解决ESM格式兼容性问题和Vite开发服务器按需加载导致的海量请求问题，如lodash-es库）

##### 单文件编译

打包第三方依赖完成后，会对项目的源码进行单文件编译，如Vue、TS、JSX文件，都会被编译为ESM，在使用ESBuild以前，这种事情一般都需要使用Babel、TSC等工具，而使用ESBuild Transformer可以做到非常快速编译文件

![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/fcd8a0393c0afe7387874fc126a4f875.png)

ESBuild Transformer无法做到TS的类型检查，因此类型检查更多的需要依赖编辑器的提示。

### 4.2.2 打包时

vite打包使用了rollup进行打包，rollup轻量的特性比较适合vite集成用来打包。

其他性质类似Webpack。

## 5.Pollyfill

在前端领域中，用来为旧浏览器提供其没有的最新原生支持的代码片段，我们将其称之为“polyfill” ，翻译过来就是“垫片”，也就是打补丁的意思

### 5.1 手动补丁

最方便的解决兼容性问题，首先想到的应该是手动写一个转换函数，将新语法转换为旧语法实现降级。比如 `Object.assign()`

其优点是，直接简单，并且天然的支持“按需”使用，不会有其他冗余代码，在性能上比较友好，但是缺点就是这不是一种工程化的解决方案，不易管理和维护，且复用性低。

### 5.2 根据覆盖率自动打补丁

`@babel/preset-env` 会根据目标环境来进行编译和打补丁，如果想在最近 3个 浏览器版本和 安卓4.4 版本以及 iOS 9.0 以上版本运行我们的代码，那么我们可以这样配置 babel

```js
...
 presets: [
 [
 '@babel/preset-env',
 {
 targets: {
 "browsers": [
 "last 3 versions",
 "Android >= 4.4",
 "iOS >= 9.0"
 ],
 }
 },
 ],
 ]
...
```



### 5.3 在线动态补丁

如果该浏览器支持该特性的话，那么针对该特性的 polyfill 就不需要引入。那么如何减少这种冗余呢？在线动态打补丁就是一个方案。

<https://polyfill.io/v3/> 就是实现该方案的服务，其提供 CDN 资源，会根据浏览器的 UA 不同，返回不同的内容。

不过现在这个网站已经失效了，据说是中国公司收购后放了恶意代码，这种CDN服务确实容易存在这类问题。

## 6.babel

### 6.1 babel是什么

Babel 是一个 JavaScript 的编译器。

Babel 的主要功能有：
- 语法转换：高级语言特性的降级
- polyfill：上一节我们介绍过的打补丁
- 源码转换：我们可以将 jsx、vue 代码转换为浏览器可识别的 JS 代码。

### 6.2 babel设计思想

Babel 的架构模式是“**插件架构模式**” 。插件架构模式的特点就是将扩展功能从核心模块中抽出为插件

![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/b5315bc6b619f39a4380670b5b85874b.png)

### 6.3 babel转译过程

`Babel` 的转译过程主要可以分为三个步骤，解析（parse）、转换（transform）、生成（generate）

分别使用到`@babel/parser`、`@babel/traverse`、`@babel/generator`



## 7.pnpm和monorepo

当一个仓库规模逐渐升级并拆分为多个模块时，可以使用`Monorepo`的方式管理仓库。些模块通常在同一仓库中依赖其他不同模块, 同时不同模块间还会互相依赖。

![项目依赖](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/1a13dd7adf106747548085b893f1a25f.png)

monorepo有pnpm和lerna两种解决方案，本文主要讲pnpm，我们先了解pnpm。

### 7.1 pnpm

pnpm又称 performant npm，翻译过来就是高性能的npm。

pnpm通过使用**硬链接**和**符号链接**（又称软链接）的方式来避免重复安装以及提高安装效率。

- **硬链接**：和原文件共用一个磁盘地址，相当于别名的作用，如果更改其中一个内容，另一个也会跟着改变
- **符号链接（软链接）**：是一个新的文件，指向原文件路径地址，类似于快捷方式

#### 7.1.1 安装依赖

下载流程

1. 解析依赖树，生成pnpm-lock.yml，如果本地没有的依赖会进行下载
2. 下载压缩包，这个阶段pnpm会开启并行下载
3. 解压压缩包
4. **通过硬连接的方式创建依赖目录，节省了大量存储空间，采用虚拟存储目录+软连接解决幽灵依赖**

#### 7.1.2 硬链接

**硬链接：** 电脑文件系统中的多个文件平等的共享同一个文件存储单元。

假如磁盘中有一个名为 data 的数据，C盘中的一个名为 hardlink1 的文件硬链接到磁盘 data 数据，另一个名为 hardlink2 的文件也硬链接到磁盘 data 数据，此时如果通过 hardlink1 文件改变磁盘 data 的数据内容，则通过 hardlink2 访问磁盘 data 数据内容是改变过后的内容。

硬链接可以有多条，它们可以指向同一块磁盘空间。



#### 7.1.3 软链接

**软链接（符号连接）：** 包含一条以绝对路径或相对路径的形式指向其他文件或者目录的引用。

最常见的就是桌面的快捷方式，其本质就是一个软链接，软链接所产生的文件是无法更改的，它只是存储了目标文件的路径，并根据该路径去访问对应的文件。



#### 7.1.4 虚拟目录

pnpm 使用一个统一的内容可寻址存储目录来存放所有下载的包。这个存储目录通常位于用户主目录下的`.pnpm-store`文件夹。

工作原理

- 当安装一个包时，pnpm 会将包的内容存储在这个全局存储目录中。每个包的文件都以哈希值命名，确保唯一性。
- 对于不同项目中相同版本的包，pnpm 只会在存储目录中保存一份副本，然后通过硬链接或软链接的方式将其链接到各个项目的`node_modules`目录中。



#### 7.1.5 幽灵依赖

幽灵依赖指的是那些没有在项目的`package.json`文件中明确声明，但却可以在项目代码中被引入和使用的依赖。

项目安装了包 A，而包 A 又依赖包 B。如果包 B 没有在项目的`package.json`中声明，那么包 B 就是幽灵依赖，B可以被使用。



### 7.2 monorepo（单仓多模块）

monorepo模式是让一个项目中的不同组件和依赖，以独立模块的方式存储在单个代码仓库中，模块与模块之前可能有依赖关系。

**monilith、multirepo、monorepo的区别**

![img](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/6498b88766889a72dc92cd035c9dbf5f.webp)

### 7.3 在pnpm中使用monorepo

在pnpm 中使用 workspace（工作空间）以支持monorepo

需要在代码仓库根目录创建`pnpm-workspace.yaml`，指定哪些目录作为独立的工作空间，这个工作空间可以理解为一个子模块或者 `npm` 包。

例如，就表示以a文件夹为一个包，b文件夹为一个包，c文件夹下所有文件夹为都为包

```yml
packages:
 - a
 - b
 - c/*
```

```
📦my-project
 ┣ 📂a
 ┃ ┗ 📜package.json
 ┣ 📂b
 ┃ ┗ 📜package.json
 ┣ 📂c
 ┃ ┣ 📂c-1
 ┃ ┃ ┗ 📜package.json
 ┃ ┣ 📂c-2
 ┃ ┃ ┗ 📜package.json
 ┃ ┗ 📂c-3
 ┃ ┗ 📜package.json
 ┣ 📜package.json
 ┣ 📜pnpm-workspace.yaml
```

`pnpm` 并**不是通过目录名称，而是通过目录下** **`package.json`** **文件的** **`name`** **字段来识别仓库内的包与模块的。**

### 7.4 monorepo之间如何相互引用

如果a包需要使用b包中的一些函数，可以在`package.json`中配置依赖

如

```json
{
 "name": "a",
 // ...
 "dependencies": {
 "b": "workspace:*"
 }
}
```



**参考文章**

- pnpm官方文档

- Webpack中文文档
- Vite中文文档
- 掘金小册《Webpack5 核心原理与应用实践》

- 掘金小册《深入浅出 Vite》

浅谈前端工程化-面试常客

> 原型的概念还是非常复杂且容易令人产生错误的，本文第一版就有很多错误概念，这里再修改后，就相对少多了 (应该吧，欢迎指出错误)



## 1. 原型概念

JS 是一门基于原型的语言，其他语言通过类描述和实例化对象，JS 通过构造函数描述和实例化对象，通过原型实现对象继承。

**JS 中几乎每个对象都有隐式原型 `__proto__`，相当于他的父对象**，但是基本没有显式原型 `prototype` (除了函数)，这里的对象可以是普通的对象、也可以是函数等，他们都会继承有其他的东西

**每个构造函数上都有一个显式原型**，用于描述创建的对象的属性和行为，**对象的隐式原型等于它构造函数的显式原型**

**当对象上找不到某个属性时，他就会往原型上寻找，原型上没有就会向原型的原型上寻找，这也就是原型链的基本概念**

## 2. 基本原型三角

![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/791b949788bd401c2dc6fcfa23c72808.png)


- 创建一个函数 `A`，在 `A` 中使用 `this` 描述要创建的对象的属性和方法，`prototype` 描述在创建的对象上继承的属性和方法，修改 `prototype` 会影响所有实例化的对象
- 实例化对象可以通过 `contructor` 获取到构造函数的引用，通过 `__proto__` 获取到原型
- 函数 `A` 的原型的构造函数实际上是函数 `A` 本身

```js
function A() {}

const f1 = new A();

// __proto__ 的引用和 prototype 的引用是相等的，但是如果修改了prototype，__proto__ 的引用不会改变
f1.__proto__ === A.prototype; // true

// f本身是没有constructor属性的，它是通过原型链找到的
f1.__proto__.constructor === A; // true

// 如果修改prototype是一个有原型的对象，新的实例化对象的构造函数不指向A
function B() {}

A.prototype = {
 constructor: B,
};

const f2 = new A();

f2.__proto__.constructor === A; // false
f2.__proto__.constructor === B; // true
// 因为f1.__proto__ 还是原来那个对象，所以f1的构造函数还是A
f1.__proto__.constructor === A; // true
```

## 3. 对象原型三角

![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/5367828d5f014882d6673492403d6ebf.png)


- **任何一个没有其他继承关系的对象的隐式原型，都是 `[Object: null prototype]{}`，而他的隐式原型最终会指向 `null`，这也就得到了原型链的终点 `null`**
- `Object` 构造函数的显式原型是 `[Object: null prototype]{}`

```js
const obj1 = new Object()

obj1.__proto__ // [Object: null prototype] {}

obj1.__proto__ === Object.prototype // true

obj1.__proto__.__proto__ // null

obj1.__proto__.constructor === Object // true
```

注：在浏览器控制台可以打印对象结构，以下是各个对象的结构
> - `Object` ![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/f8b983befe527a76083f2617e777b724.png)
> - 实例化对象 `obj1` ![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/7a2c5eb13538f6a3803f9819c553f9e7.png)
> - `obj1` 的隐式原型/ `Object` 的显式原型![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/8a28c9eb20ed243a7bafa90c79a178a1.png)

## 4. 函数原型三角

函数的构造函数和实例化函数之间的关系也比较特殊

![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/4df33f1d4af1fc98a1d0227e2439ec3f.png)

- `Function` 的显式原型和隐式原型是同一个函数，这个函数的 `constructor` 指向 `Function`
- 实例化函数 `f` 默认自带一个显式原型，这和普通的实例化对象不一样，同时这个显式原型自带一个 `constructor` 指向 `f`
- `f` 的隐式原型等于 `Function` 的原型

> 注：在浏览器控制台可以打印对象结构，以下是各个对象的结构
> - `Function`![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/853d682a1ab2956eacb49c756a66d96b.png)
> - 实例化函数 `f` ![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/edde1a714ef0027761585dd93a7ebef0.png)
> - `Function` 的原型函数![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/d2b7b5ece95b07601eacaeb1408bebf8.png)
> - `f` 的显式原型 `prototype`![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/37ea36c026bc08d8276fbe6c0c45e2c0.png)

## 5. 函数和对象的原型关系

除了函数本身的原型关系，它的原型和对象也有一定的原型关系

![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/588ff6ae5b2b16b1d7411601e981be2b.png)

```js
Function.prototype // f () { [native code] }

Function.__proto__ === Function.prototype // true

Function.__proto__.constructor === Function // true

Function.__proto__.__proto__ // [Object: null prototype] {}

Object.__proto__ // f () { [native code] }

Object.__proto__ === Function.prototype // true

Object.__proto__.constructor === Function // true
```

## 6. 原型的全貌

根据上面的分析，就可以得出原型的全貌图了，直接看的话还是太抽象了，可以拆开分析，使用代码验证。

![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/a473fe4748f6a8434ee149b3cb90ad1a.png)

浅谈原型链-面试常考

事件循环是 JS 中重要的概念，用于处理同步代码、异步代码的执行顺序问题

因为 JS 的执行环境不同，分为浏览器事件循环和 `Node.js` 事件循环





## 1. 浏览器事件循环

浏览器事件循环比较简单

 JS 的代码分为同步代码和异步代码，异步代码像这样

```js
setTimeout(() => console.log(1)); // 像setTimeout这种函数的回调是异步的
console.log(2); // 普通的同步代码
```

JS 执行代码的顺序是，先清空执行栈，再执行异步代码，也就是同步代码先执行

我们再分析异步代码

首先我们把异步代码的回调分为：宏任务和微任务，同时有一条宏任务队列和一条微任务队列。整个事件循环的过程可以为以下几步

1. 清空执行栈中的代码
2. 清空微任务队列中的代码，放到执行栈中执行
3. 如果微任务中包含有宏任务，放入宏任务队列中，如果有微任务，放入微任务队列中，直到微任务清空完毕
4. 再清空宏任务队列，先取一个宏任务，如果其中包含微任务，那执行完宏任务之后需要再清空微任务队列之后再取下一个宏任务
5. 清理完所有微任务和宏任务队列中的任务，事件循环完毕

![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/8dc875751ff83551afe0a1171e8dc1a7.png)

典型的宏任务和微任务如下
- 宏任务：`setTimeout`、`setInterval`、`requestAnimationFrame`
- 微任务：`Promise.resolve().then()`、`await之后的代码`、`MutationObserver`


比如下面

```js
setTimeout(() => console.log(1)); // 宏任务
Promise.resolve().then(() => console.log(2)); // 微任务
```

显然是 `Promise.resolve().then()` 先执行

其中有一种特殊情况，就是使用了 `async await` 关键字的函数，在使用 `await` 关键字之后的部分是异步代码

```js
async function async1() {
	console.log('async1');
	await async2();
	// await 关键字之后的代码 可以 认为是Promise.then() 
	console.log('async1 end'); 
}

async function async2() {
	console.log('async2');
}

async1()
```

**小试牛刀**

试试多层嵌套的宏任务微任务

```js
async function fn() {}
setTimeout(() => {
	console.log("Timeout 1");
	Promise.resolve().then(() => {
		setTimeout(() => {
			console.log("Timeout 2");
		}, 0);
		console.log("Promise 1");
	});
}, 0);
Promise.resolve().then(() => {
	console.log("Promise 2");
	setTimeout(async () => {
		console.log("Timeout 3");
		await fn();
		console.log("await 1");
		setTimeout(() => {
 console.log("Timeout 4");
 }, 0);
	}, 0);
});
```

可以尝试模拟任务插入队列，推出队列到执行栈中执行的过程

```
// 以下p1 t1 等为简写 (x) 表示已推出队列

// *1*
// 微任务：p2(x)
// 宏任务：t1 t3
// 输出：p2

// *2*
// 微任务：p2(x) p1(x)
// 宏任务：t1(x) t3 t2
// 输出：p2 t1 p1

// *3*
// 微任务：p2(x) p1(x) a1(x)
// 宏任务：t1(x) t3(x) t2 t4
// 输出：p2 t1 p1 t3 a1

// *4*
// 微任务：p2(x) p1(x) a1(x)
// 宏任务：t1(x) t3(x) t2(x) t4(x)
// 输出：p2 t1 p1 t3 a1 t2 t4
```

## 2. Node.js 事件循环

`Node.js` 的运行机制如下：
1. `V8` 引擎解析 JS 脚本
2. 解析后的代码，调用 `Node API`
3. `libuv` 负责 `Node API` 的执行，它将不同任务分配给不同的线程，形成一个事件循环，以异步的方式将任务的执行结果返回给 `V8` 引擎
4. `V8` 引擎再将结果返回给用户

### 1. 宏任务

`Node.js` 中会复杂一，同样还是宏任务、微任务，但是**宏任务又分为几个阶段，如下**

```
 ┌───────────────────────────┐
┌─>│ timers │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ pending callbacks │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
│ │ idle, prepare │
│ └─────────────┬─────────────┘ ┌───────────────┐
│ ┌─────────────┴─────────────┐ │ incoming: │
│ │ poll │<─────┤ connections, │
│ └─────────────┬─────────────┘ │ data, etc. │
│ ┌─────────────┴─────────────┐ └───────────────┘
│ │ check │
│ └─────────────┬─────────────┘
│ ┌─────────────┴─────────────┐
└──┤ close callbacks │
 └───────────────────────────┘
```

一般是从输入数据开始整个事件循环

常见的几个阶段对应的 `api` 有
- `poll`：一些 IO 操作，比如 `fs.readFile`
- `check`: `setImmediate`
- `close callback`: 一般不考虑，但是可以知道 `readStream.close`
- `timers`：`setTimeout`、`setInterval`
- `pending callbacks`：执行推迟到下一次循环迭代的 I/O 回调，比如 tcp 错误回调
- `idle, prepare`：仅 `Node.js` 内部使用

比如下面代码

```js
setImmediate(() => {
	console.log('check');
})

setTimeout(() => {
	console.log('timer');
})

fs.readFile('./index.js', () => {
	console.log('poll');
})

// 执行结果：
// timer
// check
// poll
```

这里顺序基本和上面一样，但是令人疑惑的是，为什么 poll 在 check 之后执行，不是说 poll -> check 吗

实际上如果是正常的同步代码，那么 poll 的回调应该马上交给队列，但是因为需要 libuv 读取文件，因此 `fs.readFile` 的回调延迟交给了队列，所以先执行了 timer 和 check

比如像下面这种情况，执行顺序就和上述的一样了

```js
fs.readFile("./index.js", () => {
	setTimeout(() => {
		console.log("timer");
	});

	setImmediate(() => {
		console.log("check");
	});

	console.log("poll");
});

// 执行结果
// poll
// check
// timer
```

对应宏任务的每个阶段，它们都是使用队列管理的，比如下面代码

```js
fs.readFile("./index.js", () => {
	setTimeout(() => {
		console.log("timer1");
		fs.readFile("./index.js", () => {
			console.log("poll2");
		});
		setImmediate(() => {
			console.log("check3");
		});
	});

	setTimeout(() => {
		console.log("timer2");
	});

	setImmediate(() => {
		console.log("check1");
		fs.readFile("./index.js", () => {
			console.log("poll1");
		});
	});
	console.log("poll");
	setImmediate(() => {
		console.log("check2");
	});
});

// 输出结果
// poll
// check1
// check2
// timer1
// timer2
// check3
// poll1 这两个poll的顺序不一定
// poll2
```

像这里，只要是同一个事件循环内 push 到队列中的任务，都需要清空相应的队列之后才会执行下一阶段队列，比如 `check` 和 `timer` 这两个阶段

而其中的 poll 因为需要 libuv 读取文件处理，有一定的延时，因此几乎不用考虑队列，因为基本不太可能两个 poll 任务在同一个事件循环内执行


### 2. 微任务

`Node.js` 环境中，微任务还有一种叫做 `process.nextTick`，`Node.js` 官网给出的解释是

> Looking back at our diagram, any time you call `process.nextTick()` in a given phase, all callbacks passed to `process.nextTick()` will be resolved before the event loop continues.
> 回顾我们的图表，任何时候在给定阶段调用 process.nextTick()，传递给 process.nextTick() 的所有回调都将在事件循环继续之前得到解决。

我的理解是，`process.nextTick` 的设计是为了能够在事件循环任何阶段开始前执行，比如下面代码

```js
// 这是一轮事件循环
setTimeout(() => {
	console.log("timer1");
})

setImmediate(() => {
	console.log("check1");
})

Promise.resolve().then(() => {
	console.log("promise1");
})

process.nextTick(() => {
	console.log("nextTick1");
})

fs.readFile("./index.js", () => {
	// 这里是新的一轮事件循环
	console.log("poll1");
	setImmediate(() => {
		console.log("check2");
	})
	setTimeout(() => {
		console.log("timer2");
	})
	process.nextTick(() => {
		console.log("nextTick2");
	})
})

// 输出结果
/** nextTick作为微任务，优先级比Promise还高，所以每次事件循环都是nextTick先执行 **/
// nextTick1
// promise1
// timer1
// check1
/** 这是新的一轮事件循环，nextTick也是在check之前就执行了，印证了官网的说法 **/
// poll1
// nextTick2
// check2
// timer2
```

在 `Node.js` 中，宏任务和微任务的执行顺序依然遵循，**先清空微任务，再执行一个宏任务，再清空微任务**这种执行顺序

**小试牛刀**

```js
const fs = require("fs");

const start = Date.now();

setTimeout(() => {
	console.log("timer1");
}, 200);

new Promise((resolve) => {
	fs.readFile("./index.js", () => {
		console.log("poll1");
		while (Date.now() - start < 500);
		setImmediate(() => {
			console.log("immediate1");
		});
		process.nextTick(() => {
			console.log("nextTick1");
			Promise.resolve().then(() => {
				console.log("promise1");
			});
		});
	});
	setTimeout(() => {
		console.log("timer2");
		resolve();
	}, 100);
}).then(() => {
	console.log("promise2");
});


// 输出结果
/** fs.readFile 完毕 开始一轮事件循环 **/
// poll1
/** nextTick 作为微任务，又有最高优先级最先执行 **/
// nextTick1
/** 推入微任务队列的Promise 立即执行 **/
// promise1
/** 到了宏任务的check阶段 **/
// immediate1
/** 到了宏任务的timer阶段，因为这个延迟时间更少，所以先执行 **/
// timer2
/** resolve promise之后，执行微任务 **/
// promise2
/** 最后执行timer1 其实当前还是在一轮事件循环的timer阶段 **/
// timer1
```

### 3. 总结规律

1. 知道基本的事件循环机制，**即先清空微任务队列，再执行一个宏任务，再清空微任务队列，以此往复**
2. 知道当前属于哪一轮事件循环，切勿将不是一轮循环的两个回调进行对比
3. 知道当前执行到宏任务的哪个阶段，下一个阶段会先清空微任务再执行，微任务中 `process.nextTick` 优先级最高