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



# 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添加启动开发服务器提示

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



## 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)

浅谈原型链-面试常考

> 本文介绍 各种包管理工具的简单原理(作者才疏学浅)，各种优势和劣势



npm、yarn、pnpm 是常见的包管理工具

他们都是将一个一个的包下载并安装在项目的 `node_modules` 中

# 1. npm

首先是 npm，它是 `node.js` 自带的包管理工具，但是在现代项目中并不常用，主要原因就是
1. 安装速度慢
2. `node_modules` 占用空间大

## 1.1 `npm install` 原理

>npm 会首先处理项目根目录下的依赖，然后逐层处理每个依赖包的依赖，直到所有依赖都被处理完毕(广度优先算法)。在处理每个依赖时，npm 会检查该依赖的版本号是否符合依赖树中其他依赖的版本要求，如果不符合，则会尝试安装适合的版本

最终形成的目录结构应该是这样的

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

比如安装 `express`

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


## 1.2 `npm install` 流程


## 1.3 `npm2.x` 和树形依赖目录

在早期 `npm2.x` 时代，`npm` 还没有支持扁平化安装，因此得到的安装目录就如上图所示

## 1.4 `npm3.x` 和扁平化依赖目录

`npm3.x` 引入了扁平化安装的方式，将所有的依赖都放到根目录来了

这会导致「幻影依赖/幽灵依赖」的问题，是指某个包未在 package.json 中定义，但项目中依然可以引用到的情况

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

但是因为 `npm install` 时，遍历 `dependencies` 是根据依赖的顺序生成的，如果顺序改变，就会导致生成的目录结构不一致

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


## 1.5 `npm5.x` 和依赖锁定

`npm5.x` 引入了 `package-lock.json` 和缓存机制（当之前安装过这个包，就会从缓存目录中直接复制到 `node_modules` 中）

**`package-lock.json`**

只有 `package.json` 时，`npm` 无法保证每次安装都能生成一样的 `node_modules` 树，也就可能导致以下问题：
1. 多人协作时，依赖不一样导致开发不一致
2. 发布上线时，服务器运行 `npm install` 生成了和在本地开发时不一样的依赖树，就可能导致线上问题
原因主要有
1. 比如 `package.json` 中声明的依赖：`A: '^1.0.5'`，因为是 `^`，所以当 `A` 升级之后，就会安装新的依赖，导致依赖树不一致（依赖升级）
2. 还是依赖 `A`，如果它依赖的 `B`，升级了，也会导致依赖书不一致，（依赖的依赖升级）

为了解决依赖不一致的问题，`npm5.x` 在 `install` 之后会生成一个 `package-lock.json` 文件
1. `npm install` 执行时，如果 `package.json` 和 `package-lock.json` 中的版本兼容，会根据 `package-lock.json` 中的版本下载；如果不兼容，将会根据 `package.json` 的版本，更新 `package-lock.json` 中的版本，然后再去下载实际包
2. `package-lock.json` 文件锁定所有模块的版本号，包括主模块和所有依赖子模块

`package-lock.json` 解决了 `npm` 无法保证每次安装都能生成一样的 `node_modules` 树的问题

## 1.6 依赖的区别

1. `dependencies` 是无论开发环境还是生产环境都会安装的依赖
2. `devDependencies` 是指可以在开发环境使用的依赖，一般指 `ESLint`、`Prettier` 这些。在打包工具中都会排除开发依赖进行打包，可以使用 `npm install --production` 仅安装生产依赖
3. `optionalDependencies` 指的是可以选择的依赖，这些依赖下载失败或者没有找到都不会影响 `npm` 的安装，但是不要和 `dependencies` 中重复
4. `peerDependencies` 用于指定你当前的插件兼容的宿主必须要安装的包的版本，在 `npm2.x` 会自动安装，`npm3.x` 之后就只会警告了，需要自行安装
## 1.7 依赖匹配符号

1. `^` 插入符号，会匹配到当前 `major version` 的最新版本，比如 `"vue": "^3.4.27"` 相当于 `"vue": "3.x.x"`
2. `～` 波浪号，会匹配到当前 `minor version` 的最新版本，也就是 `3.4.x`

# 2. yarn

## 2.1 特点

1. yarn 使用多线程的方式安装依赖，而 npm 是单线程
2. yarn 可以复用本地缓存的依赖包，相比于 npm 的缓存机制，它支持离线安装

# 3. pnpm

## 3.1 pnpm 特点

1. 极大节省了硬盘空间
2. 生成树形结构目录，而非扁平化目录，防止幽灵依赖

## 3.2 如何生成 `node_modules`

1. 使用硬连接，将已安装的包链接到 `node_modules`
2. 使用符号链接生成 `node_modules` 的嵌套结构（依赖的相互依赖关系使用软连接链接）



**参考资料**
- https://www.cnblogs.com/zhangzl419/p/15266116.html
- https://zhuanlan.zhihu.com/p/408500378
- https://pnpm.io/zh/symlinked-node-modules-structure

浅谈包管理工具npm、yarn、pnpm

事件循环是 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` 优先级最高

浅谈事件循环-面试常考

本人目前在某公司实习，公司的 Git 使用的是 SSH 连接，然后我想摸鱼 (在 Github 上开发自己的项目)，于是遇到几个问题
1. Github 的代码推送不上去
2. Github 的 commit 记录中的用户不是我的 Github 账号

首先 Git 支持两种协议管理远端仓库，分别是 SSH 和 HTTP/HTTPS



### 1. SSH 协议

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

SSH 的链接像这样：`git@github.com:arch-desgin/arch-ui-vue.git`，本地关联这个远端仓库的方式可以是

```bash
git remote add origin git@github.com:arch-desgin/arch-ui-vue.git
```

然后我们新增了 commit，`git push` 一下，会发现推送不上去，需要配置 SSH Key，具体方法可以搜索一下，最终你可以在 `~/.ssh` 目录下得到两个文件

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

把公钥放到代码托管平台，例如 github 上

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

本地再使用 Git 推送时，就可以根据有公私钥，推送代码到仓库了

同时，这套公私钥可以用于多个平台，账号（即将公钥复制到各个平台各个账号），不过注意别被盗了

或者还可以考虑配置多个 SSH Key，比如这篇文章 https://gitee.com/help/articles/4229

其中关键的点就是 `~/.ssh/config` 文件，通过配置不同平台的 SSH key，实现多个平台开发

```bash
# gitee
Host gitee.com
HostName gitee.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/gitee_id_rsa
# github
Host github.com
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/github_id_rsa
```

### 2. HTTP 协议

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

HTTP 协议链接像这样 `https://github.com/arch-desgin/arch-ui-vue.git`，同样方式管理远端仓库

首次 push 代码时，会要求输入账号密码，Github 是 Acess Token

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

输入密码之后，下次提交就不需要再次输入密码了，这是因为使用了[凭证存储](https://git-scm.com/book/zh/v2/Git-%E5%B7%A5%E5%85%B7-%E5%87%AD%E8%AF%81%E5%AD%98%E5%82%A8)，也就是 git-credential-manager 工具 (默认安装)，它的模式可以分为

- 不缓存模式
- cache 模式，凭证保存在内存中，15分钟后清除
- store 模式，存放在 home 目录下
- osxkeychain 模式，会存放在各个系统的管理密码的应用中，比如 Mac 就会存放在"钥匙串"中

> 一般情况下，git credential 默认开启了，而且是 osxkeychain 模式，以至于这种方式非常安全。
> 我们可以在"钥匙串"中访问到密码
> 
> 不过我发现一个极其恶心的问题，我并不知道密码是真的存在了 git credential 中，还是哪里，因为我删除，"钥匙串"中对应的密码后，再推送代码，它又给我一个新的密码了，比如我修改了密码，显然是无法推送的，出现了需要重新登录的 Dialog，但是把它关闭之后，你猜怎么着，又成功了
> ![|300](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/aa4f8cd5fc6334edbb5383bf35e96271.png)
> ![|300](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/4562c3f2a578c0ac9c1a48538b1c14db.png)
> 但是，在终端中是完全不受影响的，修改密码之后，就是没有再出现过密码，推送失败
> ![|300](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/858a384a5e00006ae94b085dc45b66a4.png)
> 于是我想到了，那一定是 VSCode 终端在作妖，或者 VSCode 的某个插件，比如 Gitkraken ，之后再更新
> 这块小问题的思路，有点像公司方法论中的：查找问题的关键是复现问题


### 3. 配置文件

Git 配置从高到低分为

- `.git/config` 当前仓库的配置文件，使用 `--file` 选项修改，具有最高优先级
- `~/.gitconfig` 当前用户的配置文件，可以使用 `--global` 选项修改
- `/etc/gitconfig` 系统基本的配置文件，可以使用 `--system` 选项修改

应用：
- 有这三种配置文件可以解决：比如公司开发使用单独的邮箱、用户名，通过全局配置实现，自己摸鱼 (Github 开发)可以配置仓库的 user 属性