> 深入理解 this 关键字，以及其背后的相关概念


# 参考资料

- 《你不知道的JavaScript》- this全面解析

# this 是什么

- this 是一个代词，代指一个对象
- this 提供了一种更优雅的方式来隐式的传递一个对象引用，可以让代码更加简洁易于复用

# 调用位置

调用位置就是**函数在代码中被调用的位置**（而**不是声明的位置**）。调用位置决定了 this 的绑定

比如下面代码：

```js
function baz() {
	// 当前调用栈是：baz
	// 因此，当前调用位置是全局作用域
	console.log("baz");
	bar(); // <-- bar 的调用位置
}
function bar() {
	// 当前调用栈是 baz -> bar
	// 因此，当前调用位置在 baz 中
	console.log("bar");
	foo(); // <-- foo 的调用位置
}
function foo() {
	// 当前调用栈是 baz -> bar -> foo // 因此，当前调用位置在 bar 中
	console.log("foo");
}
baz(); // <-- baz 的调用位置
```

> 可以使用浏览器的开发工具查看调用栈

| ![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/fc8a67d540079b40315bebb913592d62.png) | ![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/3d5a26abf779ed1253d5e45ec6522846.png) | ![](https://picgo-img-repo.oss-cn-beijing.aliyuncs.com/img/a045e74dc2970c0f3f72a587ede44155.png) |
| ---------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |

# this的绑定规则

this的指向有以下四条特性/规则

- 默认绑定
- 隐式绑定
- 显式绑定
- new 绑定

## 默认绑定

当函数被**独立调用**时，函数的 this 指向 window

> 独立调用就是像这样：`foo()` 的调用

比如 

```js
function foo() {
	console.log(this.a);
}
var a = 2;
foo(); // 2
```

如果使用**严格模式**（strict mode），那么全局对象将无法使用默认绑定，因此 this 会绑定到 `undefined`
## 隐式绑定

当函数引用有上下文对象 且被该对象调用时，**隐式绑定规则会把函数调用中的 this 绑定到这个上下文对象**

```js
function foo() {
	console.log(this.a);
}
var obj = {
 a: 2,
 foo: foo
};
obj.foo(); // 2
// 这里就是隐式绑定，foo函数的this绑定到了obj上
```

需要注意的是，**对象属性引用链中只有最顶层或者说最后一层会影响调用位置**

比如

```js
function foo() {
	console.log(this.a);
}
var obj2 = {
	a: 42,
	foo: foo,
};
var obj1 = {
	a: 2,
	obj2: obj2,
};
obj1.obj2.foo(); // 42
// 相当于 obj2.foo()，因为只有最后一层会影响调用位置
```

### 隐式丢失

**隐式绑定的函数可能会丢失绑定对象，也就是说它会应用默认绑定**

隐式丢失的几种情况：
1. 函数别名

```js
function foo() {
	console.log(this.a);
}
var obj = {
	a: 2,
	foo: foo,
};

// 注意这里的函数别名，会导致隐式绑定丢失，导致foo函数的this指向全局
var bar = obj.foo; // 函数别名！
var a = "oops, global"; // a 是全局对象的属性
bar(); // "oops, global"
```

2. 函数作为参数传入，并调用时

```js
function foo() {
	console.log(this.a);
}
function doFoo(fn) {
	// fn 其实引用的是 foo
	fn(); // <-- 调用位置！
}
var obj = {
	a: 2,
	foo: foo,
};
var a = "oops, global"; // a 是全局对象的属性
doFoo(obj.foo); // "oops, global"
```

> **参数传递其实就是一种隐式赋值**，因此我们传入函数时也会被隐式赋值，**所以结果和上一个例子一样**

## 显式绑定

- `fn.call(obj, x, x, ...)` 将fn函数的this指向obj，并调用，call的剩余参数是fn需要的参数

```javascript
function foo(aram) {
	console.log("foo", param.a); // foo 1

	function bar(x, y) {
		console.log("bar", this.a, x, y); // bar 1 2 3
	}
	bar.call(param, 2, 3);
}

foo({ a: 1 });
```

- `fn.apply(obj, [x, x, ...])` 将fn函数的this指向obj，并调用，apply的第二个参数是一个数组

```javascript
function foo(param) {
	console.log("foo", param.a); // foo 1

	function bar(x, y) {
		console.log("bar", this.a, x, y); // bar 1 2 3
	}
	bar.apply(param, [2, 3]);
}

foo({ a: 1 });
```

- `fn.bind(obj, x, x, ...)(x, x, ...)` 将fn函数的this指向obj，bind会返回一个新的函数，新的函数也可以传递参数

```javascript
function foo(param) {
	console.log("foo", param.a); // foo 1

	function bar(x, y) {
		console.log("bar", this.a, x, y); // bar 1 2 3
	}
	return bar.bind(param, 2);
}

const bar = foo({ a: 1 });
bar(3);
```



## new 绑定

**new 绑定** - this会绑定到新创建的对象上

```javascript
function Person(name, age) {
 // this 指向新创建的对象
 this.name = name;
 this.age = age;

 // 通过new调用构造函数时，this指向新创建的对象
	// 直接调用构造函数时，应用默认绑定规则，this指向全局或undefined
 console.log(this);
}

// 使用 new 关键字调用构造函数
const person1 = new Person("张三", 25);
console.log(person1.name); // "张三"
console.log(person1.age); // 25

// 不使用 new 调用，this 会指向全局对象(非严格模式)或 undefined(严格模式)
const person2 = Person("李四", 30); // this 不会指向新对象
console.log(person2); // undefined (因为没有显式返回)
```

# 箭头函数

1. 箭头函数没有自己的 this 指向，它需要继承外层函数的this指向
2. 箭头函数即使是new也无法改变this指向，因此箭头函数不能用于编写构造函数

```js
var a = 1;
function foo() {
	var obj1 = {
		a: 2,
		bar: function () {
			console.log("bar", this.a);
			var obj2 = {
				a: 3,
				baz: () => {
					console.log("baz", this.a);
				},
			};
			// 箭头函数不会创建自己的 this，它会捕获外层函数的 this
			obj2.baz(); // baz 2
		},
	};
	console.log("foo", this.a);
	obj1.bar(); // bar 2
}
foo(); // foo 1
```



# 如何判断函数是否被new调用了？

按照上述 new 调用规则

- 构造函数的this指向新创建的对象
- 正常调用时this指向上下文对象

而我们又知道，新对象是由构造函数实例化的，对象隐式原型的`constuctor`就是构造函数

或者简单说，`新对象 instanceof 构造函数` 

也就是 `this instaceof 构造函数`

除了这种方法，ES6中引入了`new.target`也可以判断当前函数是否被`new`

```JavaScript
function Fn() {
 if (new.target) {
 console.log("new new.target 触发");
 }
 if (this instanceof Fn) {
 console.log("new instanceof 触发");
 } else {
 console.log("正常执行");
 }
}

Fn();
new Fn();
```



# 手写 call、apply、bind

改变this指向核心是使用**隐式绑定规则**，手写时主要思路是如何让函数调用时上下文为指定对象。

## call/apply

这里只写`call`的实现，`apply`只是传递参数的方式区别

```JavaScript
Function.prototype.myCall = function (obj, ...args) {
 // 指定上下文对象，如果没传的话，默认是全局对象
 const ctx = obj || globalThis;
 // 将 函数绑定到 上下文对象上，这样就可以使用隐式绑定规则
 // ctx.fn = this;
 // 或者可以使用 Symbol 生成一个独一无二的 key，防止干扰 原对象
 const key = Symbol("fn");
 ctx[key] = this;
 // 调用并记录返回值，后续需要删除上下文上的 fn
 // const res = ctx.fn(...args);
 const res = ctx[key](...args);
 // 删除 函数，防止干扰上下文对象
 // delete ctx.fn;
 delete ctx[key];
 return res;
};
```

## bind

bind返回一个新的函数，这个函数在以下特性上需要和原函数保持一致

- new行为和原函数一致
 - 新函数 返回new实例化的对象
 - 实例化对象隐式原型需要保留
- 正常调用行为一致
 - 返回结果和原函数一致

```JavaScript
Function.prototype.myBind = function (obj, ...args1) {
 // 使用闭包特性保留 this，也就是函数
 const fn = this;

 function wrap(...args2) {
 const isNew = this instanceof wrap;
 // 如果是new调用时，应该把this传给原函数，让原函数处理this，相当于构造函数中执行的赋值
 const ctx = isNew ? this : obj;

 return fn.apply(ctx, [...args1, ...args2]);
 }

 // 保持原型链
 if (fn.prototype) {
 wrap.prototype = Object.create(fn.prototype);
 wrap.prototype.constructor = wrap;
 }

 return wrap;
};
```

全面解析this-理解this指向的原理

TypeScript 入门笔记

> JavaScript 中 作用域是让人难以理解的概念，本文简单对作用域进行讨论，介绍作用域的相关概念

# 参考内容

强烈推荐阅读原文，文章只是书籍内容的搬运和再加工

- 《你不知道的 JavaScript》:作用域和闭包（作者觉得这也是这本书比较精彩的部分）
- [JavaScript 教程 - 网道](https://wangdoc.com/javascript/) （阮一峰大佬出品，作者强烈推荐）

# 一段奇怪的代码

不卖关子，这其实是面试时很喜欢问的八股题，其实涵盖了大量作用域相关的知识，可以先看看自己能不能推出结果，再结合本文来看，会不会更简单。

```js
var a = 0;
console.log(a, window.a);
if (true) {
	console.log(a, window.a);
	a = 1;
	console.log(a, window.a);
	function a() {}
	console.log(a, window.a);
	a = 21;
	console.log(a, window.a);
	console.log("里面", a);
}
console.log("外部", a);
```

输出结果
```
0 0
ƒ a() {} 0
1 0
1 1
21 1
里面 21
外部 1
```

我们来分析这个代码
```js
// 变量声明，也叫LHS 查询，同时使用了var声明，window.a = 0
var a = 0;
// a，window.a 变量引用，也叫RHS查询，查找 "a"会沿着作用域一直查找到全局作用域 因此这里为 0 0
console.log(a, window.a);
if (true) {
	// 注意，这里隐藏了一个函数声明 function a() {}
	// 因此 a 为 func {}, window.a 当然不变，还是 0
	console.log(a, window.a);
	// 这里的 a = 1 是一个伪造的 “不成功的 LHS 查询”，因为有函数声明存在 a = 1实际上替换了 function a() {}
	// 不成功的 LHS 查询，当前作用域没有，就会泄露到上一级作用域
	// 这里还有一个需要注意的是，JS是静态作用域，也就是运行前确定了，像 a = 1这种代码，不会在编译时影响作用域的确定
	a = 1;
	// 因此这里 a = 1, window.a = 0
	console.log(a, window.a);
	function a() {}
	// 一样 a = 1 window.a = 0
	console.log(a, window.a);
	// 修改当前作用域的 a
	a = 21;
	// a = 21, window.a = 0
	console.log(a, window.a);
	// 里面 a = 21
	console.log("里面", a);
}
// 外面 a = 1
console.log("外部", a);
```

很理所应当的对吧，但是其实这里还埋了一个大坑，那就是 **块级作用域 Web 兼容语义**

```js
// 'use strict'
var a = 0;
console.log(a, window.a);
if (true) {
	console.log(a, window.a);
	a = 1;
	console.log(a, window.a);
	// 注意这里的函数声明，因为 ES6 块内的函数声明应该只在块内可见，导致了函数声明提升会到 if 顶端
	// 也就导致第一个 log 是 "f a{} 0"
	// 而第二个 a = 1 修改了这个函数声明，导致了第二个 log 是 "1 0"
	// 真正执行到函数体这里时，发生了兼容行为，函数a赋值给了外层的 a 变量
	// 但是if块语句中的a其实被修改了，所以导致外层的a也就是window.a也等于1
	// 所以第三个log意外的是 “1 1”
	// 最后的 a = 21还是在修改if块语句中的 a变量
	// 所以第四个log是“21 1”
	// 后面的都能猜到是什么了
	function a() {}
	console.log(a, window.a);
	a = 21;
	console.log(a, window.a);
	console.log("里面", a);
}
console.log("外部", a);
```

# js 引擎 V8 

**是什么**：一个庞大的函数，提供了执行 js 代码的能力

**有什么用**：读取网页中的 JavaScript 代码，对其处理后运行

**JavaScript 是一种解释型语言，也就是说，它不需要编译，由解释器实时运行**。这样的好处是运行和修改都比较方便，刷新页面就可以重新解释；缺点是每次运行都要调用解释器，系统开销较大，运行速度慢于编译型语言。

**为了提高运行速度，目前的浏览器都将 JavaScript 进行一定程度的编译，生成类似字节码（bytecode）的中间代码，以提高运行速度**。

**现代浏览器改为采用“即时编译”**（Just In Time compiler，缩写 JIT），**即字节码只在运行时编译，用到哪一行就编译哪一行，并且把编译结果缓存（inline cache）**。通常，一个程序被经常用到的，只是其中一小部分代码，有了缓存的编译结果，整个程序的运行速度就会显著提升
## 运行环境

现代 js 代码运行在浏览器和 node 环境中

1. 浏览器
2. node

## v8执行js代码的过程

v8运行代码分为两步
1. 预编译
2. 运行代码

预编译过程大概概括为：
1. 分词/词法分析
2. 解析/语法分析 --- AST
3. 代码生成

# RHS 查询 和 LHS 查询

js 中对变量的操作可以概括为 LHS 查询和 RHS 查询两种操作

**LHS 查询**：如果查找的目的是对变量进行赋值，那么就会使用 LHS 查询

**RHS 查询**：如果目的是获取变量的值，就会使用 RHS 查询

```js
function foo(a) {
	var b = a;
	return a + b;
}
var c = foo(2); // foo(2) 是为了获取返回值，赋值给c，所以是RHS
// 1. 找出所有的 LHS 查询（这里有 3 处！）
// c = ..;、a = 2（隐式变量分配）、b = ..
// 2. 找出所有的 RHS 查询（这里有 4 处！）
// foo(2..、= a;、a ..、.. b
```

> **实参赋值，就是一种隐式变量分配**
> 
> function 函数名(形参1， 形参2，...) { //函数声明的小括号里的是形参
> // 函数体代码
> }
> 函数名(实参1， 实参2，...); //函数调用的小括号里的是实参

**注意：**
1. 不成功的 RHS 引用会导致抛出 `ReferenceError` 异常。
2. 不成功的 LHS 引用会导致自动隐式地创建一个全局变量（非严格模式下），该变量使用 LHS 引用的目标作为标识符，或者抛出 `ReferenceError` 异常（严格模式下）。
# 变量声明

js 中，声明变量有：var、let、const，三种方法

**var 和 let 以及 const 的区别**

| var | let/const |
| ----------------------------------------------- | ---------------------------------------------- |
| 存在**变量提升**，可以在变量声明前使用，读取值时为 `undefined` | 不存在变量提升，不可以在变量声明前使用变量，否则会造成**暂时性死区**（TDZ），发生报错 |
| 在同一作用域中，**允许变量重复声明** | 在同一作用域中，**不允许变量重复声明** |
| 在全局作用域中，var 声明的变量会挂在到全局对象（`globalThis`）上，成为它的属性 | let/const 声明的对象不会有这个问题 |
| var 声明的变量没有块级作用域，只有全局作用域和函数作用域 | let/const 声明的变量具有块级作用域，函数作用域和全局作用域 |

**const 和 let 的区别**

|const|let|
|---|---|
|const 声明的变量的值后续不可修改|let 声明的变量的值后续可以修改|
|在使用 const 声明变量时必须同时进行初始化|不用|

## 声明提升

**声明提升**：是指像 `var` 或者 `function` 关键字 定义的标识符，在声明之前就可以使用

```js
// 变量提升
function foo() {
	a = 3;
}
// 在声明之前使用RHS，结果是undefined
console.log(a); // undefined
foo();
// foo内执行了LHS，a被提升到全局作用域，修改了a，因此值为3
console.log(a); // 3
// 代码执行到这，才真正赋值a=2
var a = 2;
console.log(a); // 2
```

函数提升不同的是，**函数的函数体也会提升，因此在函数声明之前就可以使用函数**
```js
// 函数提升
foo(); // foo

function foo() {
 console.log('foo');
}
```

## 暂时性死区

**当作用域中使用 let/const 声明了变量，就会形成暂时性死区**，在变量声明之前不能使用变量，即便是外部已经声明过，也会报错 `ReferenceError: Cannot access 'a' before initialization`

```js
let a = 1
function foo() {
 console.log(a);
 let a = 2;
}

foo() // ReferenceError: Cannot access 'a' before initialization
```

## 重复声明

同一个作用域中，使用 `var` 可以重复声明，使用 `let/const` 不能重复声明，会报错 `SyntaxError: Identifier 'a' has already been declared`

```js
var a = 1
var a = 2 // 不报错，可以重复声明
console.log(a)
```

```js
// 预编译阶段报错
let b = 1
let b = 2 // SyntaxError: Identifier 'b' has already been declared
console.log(b)
```
## 不成功的 LHS 查询

- 一般就是指 `a=2` 这种赋值，如果标识符找不到，就会**隐式创建全局变量**
```js
function foo() {
	a = 2; // LHS 查询失败，自动创建一个全局变量
}
foo();
console.log(a);
```

# 作用域

**作用域的定义：**
- 作用域是一套规则，用于确定在何处以及如何查找变量（标识符）。
- （或者是一个容器，包含了标识符的定义，和查找规则）

## 作用域有哪些

1. 全局作用域
2. 函数作用域
3. 块级作用域

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


## 作用域查找规则

1. **由内向外查找**：现在当前作用域中查找，找的到就返回，找不到就去外层作用域中查找
2. **不能由外向内查找**：外层的作用域无法查找内层作用域的变量

## 遮蔽效应

**作用域查找会在找到第一个匹配的标识符时停止**。

在多层的嵌套作用域中可以定义同名的标识符，这叫作“**遮蔽效应**”（内部的标识符“遮蔽”了外部的标识符）。

```js
var a = 1;

function foo() {
	var a = 2; // 遮蔽外层 a = 1
	function bar() {
		var a = 3; // 遮蔽外层 a = 2
		console.log("bar", a);
	}
	bar();
	console.log("foo", a);
}

foo()
```

## 作用域链

因为作用域“由内向外”的查找规则，查找某个变量时，会有如下特点：
1. 现在当前作用域中查找，如果找到则结束查找，如果没找到则向外查找
2. 在外层作用域中查找到，则结束查找，如果没有则一直找到全局作用域为止

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

## 作用域的两种工作模型

**作用域共有两种主要的工作模型**。
1. 第一种是最为普遍的，被大多数编程语言所采用的**词法作用域**(也叫静态作用域)。
2. 另外一种叫作**动态作用域**，仍有一些编程语言在使用（比如 Bash 脚本、Perl 中的一些模式等）。

# 词法作用域

大部分标准语言编译器的第一个工作阶段叫作**词法化**（也叫单词化）

词法化的过程会**对源代码中的字符进行检查**，如果是**有状态的解析过程，还会赋予单词语义**。

词法作用域就是定义在**词法阶段的作用域**。词法作用域是**由你在写代码时将变量和块作用域写在哪里来决定的**，因此**当词法分析器处理代码时会保持作用域不变**（大部分情况下是这样的）。

## 欺骗词法

**欺骗词法是什么**：

作用域是在词法阶段形成的，因此在运行代码时应该不会改变，而**欺骗词法**是一种手段，**可以在运行代码时修改作用域**

1. with --- 当 with 修改对象中不存在的属性时，会导致该属泄露到了全局（本质上是**不成功的 LHS 查询**，导致泄露）

```js
function foo(obj) {
	with (obj) {
		a = 2;
	}
}

var o1 = { a: 3 };
var o2 = { b: 3 };

foo(o1);
console.log(o1.a); // 2

foo(o2);
console.log(o2.a); // undefined
console.log(a); // 2——不好，a 被泄漏到全局作用域上了！
```

2. eval --- 将本不属于当前作用域的代码，强行添加到当前作用域中执行

```js
function foo(str, a) {
	eval(str); // 欺骗！ 
	console.log( a, b );
}

var b = 2;

foo("var b = 3;", 1); // 1, 3
```

> 1. `eval(..)` 函数如果接受了**含有一个或多个声明的代码**，就**会修改其所处的词法作用域**
> 2. `with` 声明实际上是根据你传递给它的对象凭空**创建了一个全新的词法作用域**

**性能问题**
- 这两个机制的副作用是**引擎无法在编译时对作用域查找进行优化**，因为引擎只能谨慎地认为这样的优化是无效的。使用这其中任何一个机制都将导致代码运行变慢

# 函数作用域和块级作用域

**函数作用域的含义**是：属于这个函数的全部变量都可以在整个函数的范围内使用及复用

```js
function foo() {
 var a = 1
 console.log(a) // 1
}

foo()
console.log(a) // ReferenceError: a is not defined
```

**块级作用域的定义**是：`{}` 声明的标识符，在 `{}` 范围内使用
- `with` 关键字创建的作用域，只能在 `with{}` 内使用
- `try catch` 的 `catch err` 只能在 `catch{}` 内使用 
- `let/const` 关键字可以将变量绑定到所在的任意作用域(也包含块级作用域)中，因此几乎是任意 `{}` 内都可以使用 `let/const` 声明变量而不泄漏到外部作用域

```js
function foo() {
	var a = 1;
	if (true) {
		let b = 2; // let/const 在
		var c = 3;
		console.log(a, b, c); // 1, 2, 3
	}
 console.log(a, b, c);
}

foo()
```

# 块级作用域 Web 兼容语义

[ECMAScript® 2026 Language Specification](https://tc39.es/ecma262/#sec-block-level-function-declarations-web-legacy-compatibility-semantics)

> 其实这个规范很难看懂，我向 AI 问了问，他的回答是这样

## ES5时期的行为

在 ES5中，没有块级作用域，所有函数声明都会被提升到包含它们的函数作用域顶部：

````javascript
function test() {
 console.log(typeof foo); // "function" - 函数声明被提升
 
 if (false) { // 即使条件为false
 function foo() {
 return "hello";
 }
 }
 
 console.log(typeof foo); // "function" - 在ES5中仍然可以访问
}
````

## ES6块级作用域的冲突

ES6引入块级作用域后，按严格规范，**块内的函数声明应该只在块内可见**：

````javascript
// ES6严格模式下的预期行为
function test() {
 if (true) {
 function foo() {
 return "hello";
 }
 // foo只在这个块内可见
 }
 // 这里应该访问不到foo
}
````

## Web 遗留兼容性方案

为了不破坏现有代码，引入了双重绑定机制：

````javascript
// 实际的兼容性行为
function test() {
 var foo; // 隐式创建var绑定（值为undefined）
 
 if (true) {
 function foo() { // 块内函数声明
 return "hello";
 }
 // 值得注意的是：如果在块级作用域中修改了 foo，执行到声明函数的语句，也会把被修改的函数声明赋值给外层
 // 执行到这里时，将块内函数赋值给外层var
 }
 
 console.log(foo); // 可以访问到函数
}
````

**值得注意的是：如果在块级作用域中修改了 foo，执行到声明函数的语句，也会把被修改的函数声明赋值给外层**

## 严格模式的区别

在**严格模式**下，行为完全不同：

````javascript
"use strict";

function test() {
 if (true) {
 function foo() {
 return "hello";
 }
 console.log(foo); // 正常工作
 }
 
 console.log(foo); // ReferenceError: foo is not defined
}
````

## 对比总结

| 模式 | 块外访问性 | 提升行为 |
|------|-----------|----------|
| ES5 | ✅ 可访问 | 完全提升到函数顶部 |
| ES6非严格模式 | ✅ 可访问 | 双重绑定兼容机制 |
| ES6严格模式 | ❌ 不可访问 | 仅在块内有效 |

## 实际测试

````javascript
// 非严格模式
function nonStrict() {
 console.log(typeof foo); // "undefined"
 if (true) {
 function foo() { return "hello"; }
 }
 console.log(typeof foo); // "function" - 兼容性行为
}

// 严格模式
function strictMode() {
 "use strict";
 if (true) {
 function foo() { return "hello"; }
 }
 // console.log(foo); // ReferenceError
}
````

浅谈 作用域

>NAT（Network Address Translation）是一种网络地址转换技术，主要用于解决IPv4地址不足的问题。它允许内网中的多个设备共享一个或少数几个公网IP地址来访问互联网。NAT通过修改数据包的IP地址和端口号来实现地址转换。




参考这个 UP 主的几个视频
- [P2P技术科普与应用(基于 TCP 打洞实现的内网穿透服务)\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV1VC4y1u7aR)
- [基于 UDP 打洞实现的内网穿透教程\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV1Vi4y1r7DS)
- [P2P 内网穿透通信之 NAT 类型介绍\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV1bg4y1U724)
- [基于TCP NAT3打洞实现P2P内网穿透聊天室\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV1mi4y1W7cb)
- [Nat4 实现 p2p 通信和 PCDN 分发的基本原理\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV1fFiceEEwF)
# NAT

NAT 类型在线测试网站
- [Check My NAT](https://www.checkmynat.com/)
- [NAT类型在线检测工具,查看我的NAT类型 – 猫点饭](https://mao.fan/mynat)（需要微信登录，稍微麻烦）

国光的文章
- [NAT类型 - 国光的 PVE 环境搭建教程](https://pve.sqlsec.com/8/1/)

相关 NAT 科普文章
- [NAT和NAT打洞基本原理 - bfhyqy - 博客园](https://www.cnblogs.com/bfhyqy/p/18051907)
- [STUN, TURN, ICE介绍-阿里云开发者社区](https://developer.aliyun.com/article/243540)
## NAT 概念

NAT（Network Address Translation）是一种网络地址转换技术，主要用于解决IPv4地址不足的问题。它允许内网中的多个设备共享一个或少数几个公网IP地址来访问互联网。NAT通过修改数据包的IP地址和端口号来实现地址转换。

通俗的说，我们联网设备（手机/电脑），其实都会有一个公网 IP，当我们访问网页时，服务器可以看到请求的 IP。

但是这个 IP 并不是独有的，而是运营商将一个公网 IP 分配给了多个用户，我们只是暂时有他的使用权。

具体原理是，我们的请求到达运营商的 NAT 转换设备，它按照拥有的公网 IP 临时分配一个端口给我们，以保证请求可以正确发出。

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

## 四种 NAT
| NAT类型 | 名称 | 特点 | P2P穿透难度 | NAT 穿透后可做什么 |
| ----- | ----------------------------------- | --------------------------------------------------------- | ------- | --------------------------------------------------------------------- |
| NAT1 | Full Cone NAT 完全圆锥型 | • 最宽松的NAT类型 • 任何外部主机都可以通过映射端口访问内网 • 不限制外部IP和端口 | 最容易 | • 支持HTTP 302重定向直连 • 可实现真正的无服务器P2P • 适合文件共享、游戏服务器 • 支持多方同时连接 |
| NAT2 | Restricted Cone NAT 受限圆锥型 | • 限制外部主机IP地址 • 只有内网曾发送过数据的外部IP才能访问 • 不限制外部端口号 | 较容易 | • 需要双向握手建立连接 • 不能使用302重定向（IP限制） • 适合点对点聊天、VoIP • 需要STUN服务器协助 |
| NAT3 | Port Restricted Cone NAT 端口受限圆锥型 | • 同时限制外部IP地址和端口号 • 必须是完全相同的IP:端口组合才能访问 • 最严格的圆锥型NAT | 较困难 | • 必须精确匹配IP和端口 • 需要同步UDP打洞 • 适合WebRTC等标准协议 • 多数游戏需要UPnP辅助 |
| NAT4 | Symmetric NAT 对称型 | • 最严格的NAT类型 • 每次向不同外部地址通信都可能使用新端口 • 具有端口受限的所有特性 | 最困难 | • 基本无法直接P2P连接 • 必须使用TURN中继服务器 • 适合企业级安全应用 • 大多数应用退化为C/S模式 |

# DDNS

- [IPv6 DDNS - 国光的 PVE 环境搭建教程](https://pve.sqlsec.com/8/3/)
# 内网穿透

因为没有公网 IP，所以如果我们想部署互联网服务，比如网站、游戏服务器、网盘，等等，就需要购买云服务器。而云服务器不仅价格昂贵且配置低下，如果不想购买服务器，可以使用内网穿透的方案。

而内网穿透大概有两种方案
- NAT 穿透
- 服务器中转
## NAT 穿透

NAT 实际上会分给我们一个临时的公网 IP，而我们利用上这个公网 IP，就可以实现大带宽的网络传输。

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

> NAT1 穿透，可以实现几乎等同于公网的访问体验，但是国内基本都是 NAT3 NAT4，这种方案也就不可行了。


常见的 NAT 穿透工具有
- tailscale
- zerotier
- easytier

## 服务器中转

在难以进行 NAT 穿透的网络中，服务器中转成为唯一选择

事实上，上面提到的 NAT 穿透软件，都有穿透失败降级服务器中转的功能

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

服务器中转方案，可以使用工具 frp

NAT 、DDNS 与 内网穿透

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



本文还参考了如下翻译版本：[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