阮超民的网络日志

2025｜风吹过钱塘江，我走过这一年

2026-04-30T11:40:57Z

前言

嘿嘿，好久没有更新博客了。一时间也不知道写什么，那就从今年的总结开始吧。虽然很久没写博客文章，但博客本身还是一直在维护。

今年给博客加了新的「动态」模块，可以随手记录一些照片；也新加了「关于」页面，放了一点自己的介绍。前几天还把博客里所有图片的图床统一迁移到了 Cloudflare。

出行

今年一共请了 14.5 天假，把往年的假期和 2025 年的假期都用光了。真正出去玩的只有南京一趟，其余时间基本都在福州和杭州之间来回穿梭。下面是今年的出行记录：

时间	行程
2025-01-24 → 2025-02-06	杭州 ⇄ 南京 ⇄ 福州 ⇄ 杭州
2025-04-03 → 2025-04-06	杭州 ⇄ 福州
2025-04-30 → 2025-05-06	杭州 ⇄ 福州
2025-05-30 → 2025-06-03	杭州 ⇄ 福州
2025-07-11 → 2025-07-14	杭州 ⇄ 福州
2025-09-26 → 2025-10-08	杭州 ⇄ 福州
2025-11-13 → 2025-11-17	杭州 ⇄ 福州
2025-12-26 → 2026-01-03	杭州 ⇄ 福州

高德地图的年度报告：

运动

2025 年，我最喜欢的运动是骑行。杭州滨江的樱花大道，在记忆里仍然盛放——那里，是我第一次骑行的地方。也正是从那一刻开始，慢慢爱上了骑行。后来常常沿着钱塘江边骑上一圈，耳机里放着喜欢的音乐，夏日的微风从身侧掠过，心也变得轻快而自由。只是最近没再出发，冬日的杭州有些冷，车轮也需要休息。等春风再起的时候，再出发。

工作

工作之后，时间仿佛开始加速，一转眼已经在这家公司走过四年。依旧大小周，工作日大多从早上九点半到晚上九点。今年做了新的项目，日子被任务与项目填满，但也在不断积累经验与成长。

2025 年通过了年度晋升，从“普通牛马”升级为“高级牛马”。称谓在变，责任也在变，手里的事情变得更多、更复杂了。有时候也挺累的，但在这一份忙碌里，也确实看到了自己逐渐成长与沉淀。

搬家

2025 年的睡眠状态不算理想，经常失眠，工作之后也常常熬夜。在这个小区已经住了四年，中间第二年搬过一次，只是换到隔壁幢，那次还挺顺利。后来又在这里住了三年。

今年十月份开始，楼上噪音不断。忍了两个月后，在到期前一周搬了家。算一算，在杭州已经待了四年多，这是第三次搬家：第一次从余杭到滨江，第二次搬到隔壁幢，而这一次，换了个新的小区，离公司更近就几百米。

现在的新家，偶尔楼上也会有些声音，但整体环境已经好了不少，搬家前后的睡眠质量对比也记录了下来：

周末

大小周的节奏里，单休大多用来补觉，把工作日欠下的睡眠还回来。双休的日子，要么去跑步、骑行，要么在城里闲逛，和朋友吃吃喝喝。西湖去了很多次，钱塘江边也走了无数遍。

周末闲暇时，听着音乐下厨做点喜欢吃的东西，成了最治愈的时刻。只是——吃了那么多，好像还是很难长胖。

后记

用最近看到的这段话作为结尾：

目前时代的红利只有一个，身体保持健康。因为大家现在卷的不是工作，不是房和车，而是良好心态和深度睡眠。当所有人都在信息过载、焦虑失眠的泥潭里打滚时，你能吃得好，睡得着，情绪稳定，精力充沛，这本身就是一种降维打击，你的身体，才是你在这个时代最硬核的生产资料和安全资产。还有一个更关键的理由，科技爆炸带来的寿命红利，只留给那些能活到并能接得住的人。

新的一年，少熬点夜，吃得香睡得好，健康快乐，比什么都重要。

祝读到这里的你，2026年一切安好。

Chrome DevTools 奇技淫巧

2026-05-02T09:20:54Z

前言

Chrome DevTools 是每位前端开发者的得力助手，它提供了丰富的功能和工具，帮助我们诊断和调试网页应用程序。本文将分享一些 Chrome DevTools 的调试技巧，在开发中提高效率。

2023年9月12日，Chrome 团队发布了 Chrome 117 桌面稳定版，本文将使用最新版本介绍。

模拟接口响应和网页内容

通过本地覆盖可以模拟接口返回值和响应头，无需 mock 数据工具，无需等待后端支持，快速复现在一些数据下的 BUG 等。在 DevTools 可以直接修改你想要的 Fetch/XHR 接口数据，还可以修改响应头，解决跨域等问题，不仅可以覆盖 Fetch/XHR，JS、CSS 等资源也可以。

本地覆盖其实在之前的版本就已经有了，需要在本地手动创建目录，步骤麻烦。Chrome 117 对本地覆盖功能简化，现在可以直接在 Network 面板快速模拟远程资源的内容和响应头！如下图演示：

设置本地覆盖步骤：

打开 DevTools，导航至 Network 网络面板，右键单击要覆盖的请求，从下拉菜单中选择 Override content 或 Open in Sources panel。
如果是首次使用，未设置过本地覆盖文件目录，DevTools 会在顶部的操作栏中提示您选择一个文件夹来存储覆盖文件，并 “允许” 授予 DevTools 对其的访问权限（在 window 下选择了系统盘的文件夹测试发现用不了，可能是权限问题，建议选个非系统盘的文件夹）。
在 Sources 面板中修改数据，完成后按 Ctrl + S 保存，刷新页面，即可看见修改后的数据（被覆盖的资源在图标右下角会有个紫色的圆点）。
若要恢复使用服务上的数据，请导航到 Sources > Overrides，可以点击取消 “Enable local overrides” 复选框，或者点击旁边的 Clear 图标，或者如上图演示中的单个删除。

它是怎么工作的？

当你在 DevTools 中进行更改时，DevTools 会将修改后的文件的副本保存到您指定的文件夹中。
当你重新加载页面时，DevTools 会提供本地修改后的文件，而不是网络资源。所以在旧版本支持 Override 的版本中，也可以手动创建一个文件来覆盖内容。

快速重发请求

在联调接口或者排查 BUG 的时候，经常需要重新再发一次请求，如果要重新操作一次复杂的交互、重新输入一大堆参数时，这种方式会显得比较麻烦。

这时候就可以通过 Replay XHR 来快速重发请求，如下图演示：

操作步骤：

导航至 Network 网络面板，右击一个 XHR 请求，可以点击 Fetch/XHR 过滤。
点击 Replay XHR。

在 Console 中发请求

针对上面同样的场景，有时候我们需要修改请求头、入参再重新发起请求，那么 Replay XHR 就不支持了。

可以通过 Copy as fetch ，在控制台修改请求参数，发起请求，如下图演示：

操作步骤：

导航至 Network 网络面板，右击一个 XHR 请求，可以点击 Fetch/XHR 过滤。
点击 Copy -> Copy as fetch。
导航至 Console 面板，Ctrl + v 粘贴。
修改内容，如接口 url、header、body，然后按回车键即可发起请求。

条件断点

如果我们在某个循环中，希望循环到某个条件的时候在进入断点。
此时我们就可以使用 conditional breakpoint 如下图演示：

操作步骤：

右击代码行，点击 Add conditional breakpoint，或者按住 Ctrl + 鼠标左点击代码行。
输入条件表达式。

Add log point 为条件日志，可以不用在代码中写 console.log。

Console 中的 $

$0-$4

当要在 Console 中在调试页面元素时，比如要获取元素的信息，此时就可以使用 $0-$4。

$0：当前选择的元素，$1：上一次的引用，$2：上上次的引用，一直到 $4

例如获得某个元素相对于其 offsetParent 元素的顶部内边距的距离，演示如下：

操作步骤：

点击菜单栏第一个选择图标，或者使用快捷键 Ctrl + Shift + C 选择元素。
导航至 Console 面板，现在就可以使用 $0-$4，例如选择了两次，第一次选择的元素可以使用 $1 访问，第二次选择的元素使用 $0 访问。

$ 和 $$

$(‘xxx’) 相当于 document.querySelector(‘xxx’)
$$(‘xxx’) 相当于 Array.form(document.querySelectorall(‘xxx’))

如下图演示：

$_

调试的过程中，经常需要打印一些变量值，但是如果想查看上一次执行的结果，使用 $_ 是对上次执行结果的引用。

$i

现在的前端开发过程，离不开各种 npm 包，如果我们要测试一个 npm 包，需要先在本地npm init，然后再 npm install xxx。

Console Importer 插件可以帮助我们，在控制台使用 $i(‘xxxx’) 进行装包，并进行调用。

Element 面板

隐藏 DOM Element

有时候我们想截图，但是想要隐藏图中的敏感信息，此时就可以隐藏元素，如下图演示：

操作步骤：

右键 DOM Element，点击 Hide Element。也可以使用键盘快捷键，点击选中 Element 后，按键盘 H 键。

一键展开所有 DOM

在调式 DOM Element 的时候，如果 DOM 层次比较深的情况下，一个个去展开就比较麻烦，我们可以使用快捷键 Alt + Click 一键展开该层下的所有 DOM，如下图演示：

拖拽移动 DOM Element

当我们想看页面某一部分元素在不同的位置显示效果的时候，可以直接拖拽 DOM 元素调整位置，也可以使用键盘快捷键 Ctrl + 上下箭头。如下图演示：

截图

如果想要截取多屏很长的整个页面内容，系统自带的截图软件显然不支持，此时可以使用 command 命令截图，如下图演示：

操作步骤：

按 Ctrl + Shift + P 调出 command 命令
输入命令 capture full size screenshot 后回车。

截图 command：
截框选区域：capture area screenshot
截滚动全屏：capture full size screenshot
截选中的节点：capture node screenshot
截当前窗口内：capture screenshot

还有很多其他的命令，如切换主题 Switch to Dark theme，查看所有快捷键 Show shortcuts 等等。

总结

本文介绍了 Chrome DevTools 的调试技巧和最新版本 Chrome 117 中的新功能，包括模拟接口响应和网页内容、快速重发请求、在 Console 中发请求、Console 中的快捷命令、条件断点、Element 面板以及截图命令，这些调试技巧有助于我们在开发中提高效率。

参考
What’s New in DevTools (Chrome 117)
Override web content and HTTP response headers locally
Chrome DevTools

JavaScript 设计模式

2026-04-28T09:30:02Z

引言

JavaScript 设计模式是一种解决特定问题的可复用解决方案，旨在提高代码的可维护性、可读性和可扩展性。设计模式是软件开发中的重要概念，它们为我们提供了一种组织和构建代码的方式，使代码更加优雅和可重用。

示例代码： javascript-design-patterns

在线运行： JavaScript design pattern

设计模式分类

创建型设计模式

单例模式（Singleton Pattern）

用于确保一个类只有一个实例，并提供一个全局访问点来访问该实例。它主要用于限制类的实例化次数，避免多个实例的创建和资源的浪费。

下面是一个单例模式的示例：

class Singleton {
  constructor() {
    if (!Singleton.instance) {
      this.data = [];
      Singleton.instance = this;
    }
    return Singleton.instance;
  }
  addItem(item) {
    this.data.push(item);
  }
  getItems() {
    return this.data;
  }
}
// 示例使用
const instance1 = new Singleton();
instance1.addItem('Item 1');
const instance2 = new Singleton();
instance2.addItem('Item 2');
console.log(instance1.getItems()); // 输出: ['Item 1', 'Item 2']
console.log(instance2.getItems()); // 输出: ['Item 1', 'Item 2']
console.log(instance1 === instance2); // 输出: true

在上述示例中，我们定义了一个 Singleton 类，它具有一个私有的静态属性 instance 来存储单例实例。构造函数中使用了一个条件判断，如果 instance 不存在，则创建实例并将其赋值给 instance，否则直接返回 instance。

还可以使用 ES6 的 Proxy 来封装实现单例模式：

export default function SingletonPattern(className){
    let instance;
    return new Proxy(className,{
        construct(target, argArray) {
            if(!instance){
              instance = new target(...argArray)
            }
            return Object.freeze(instance);
        }
    })
}

import SingletonPattern from "./SingletonPattern";
class Person {
    constructor(name,age) {
        this.name = name;
        this.age = age;
    }
}
export default SingletonPattern(Person);

import person from "./Person";
const zs = new person('zs',18);  // Person {name: 'zs', age: 18}
const ls = new person('ls',20); // Person {name: 'zs', age: 18}
console.log(zs === ls); // true

通过使用单例模式，我们可以确保只有一个实例存在，并且可以通过全局访问点来访问该实例。这样可以实现对共享资源的统一管理和访问，并且能够避免重复创建实例。

工厂模式（Factory Pattern）

用于封装对象的创建逻辑，并统一通过工厂方法创建对象。它通过将对象的实例化过程封装在一个工厂函数中，使得创建对象的代码与具体对象的实现解耦，提供了更灵活和可维护的对象创建方式。

可以根据不同的条件或参数，返回不同的具体对象实例，实现了对象的多态性和可定制性。

下面是一个工厂模式的示例：

// 具体车辆类
class SedanCar {
  constructor() {
    this.type = 'sedan';
  }
}
class SUVCar {
  constructor() {
    this.type = 'suv';
  }
}
class SportsCar {
  constructor() {
    this.type = 'sports';
  }
}
// 工厂类
class CarFactory {
  createCar(type) {
    switch (type) {
      case 'sedan':
        return new SedanCar();
      case 'suv':
        return new SUVCar();
      case 'sports':
        return new SportsCar();
      default:
        throw new Error('Can only be sedan or suv or sports');
    }
  }
}
// 示例使用
const factory = new CarFactory();
const sedan = factory.createCar('sedan');
const suv = factory.createCar('suv');
const sports = factory.createCar('sports');
console.log(sedan.type); // 输出: sedan
console.log(suv.type); // 输出: suv
console.log(sports.type); // 输出: sports

在上述示例中，我们定义了具体的车辆类包括 SedanCar、SUVCar 和 SportsCar，它们都具有一个 type 属性用于标识车辆类型，还有一个 CarFactory 工厂类，它具有一个 createCar 方法用于根据车型参数创建具体的车辆对象。

通过调用 CarFactory 的 createCar 方法，并传入相应的参数，工厂类会根据参数返回相应类型的车辆对象。

通过工厂模式，我们可以封装对象的创建过程，使得创建对象的代码与具体对象的实现解耦，提供更灵活和可维护的对象创建方式。

抽象工厂模式（Abstract Factory Pattern）

用于提供一个接口来创建一系列相关或依赖对象的工厂。它可以通过抽象工厂和具体工厂的组合，创建一组相互关联的对象，而无需指定具体的类。

抽象工厂模式适用于需要创建一组相关对象的情况，这些对象在某种上下文中需要协同工作，或者需要保持一致的风格或主题。

下面是一个抽象工厂模式的示例：

// 抽象工厂类
class AbstractCarFactory {
  createSedanCar() {
    throw new Error('This method must be implemented.');
  }
  createSUVCar() {
    throw new Error('This method must be implemented.');
  }
}
// 具体产品类 - 奔驰轿车
class MercedesSedanCar {
  constructor() {
    this.type = 'Mercedes Sedan';
  }
}
// 具体产品类 - 奔驰SUV
class MercedesSUVCar {
  constructor() {
    this.type = 'Mercedes SUV';
  }
}
// 具体产品类 - 宝马轿车
class BMWSedanCar {
  constructor() {
    this.type = 'BMW Sedan';
  }
}
// 具体产品类 - 宝马SUV
class BMWSUVCar {
  constructor() {
    this.type = 'BMW SUV';
  }
}
// 具体工厂类 - 奔驰车工厂
class MercedesCarFactory extends AbstractCarFactory {
  createSedanCar() {
    return new MercedesSedanCar();
  }
  createSUVCar() {
    return new MercedesSUVCar();
  }
}
// 具体工厂类 - 宝马车工厂
class BMWCarFactory extends AbstractCarFactory {
  createSedanCar() {
    return new BMWSedanCar();
  }
  createSUVCar() {
    return new BMWSUVCar();
  }
}
// 示例使用
const mercedesFactory = new MercedesCarFactory();
const mercedesSedan = mercedesFactory.createSedanCar();
const mercedesSUV = mercedesFactory.createSUVCar();
const bmwFactory = new BMWCarFactory();
const bmwSedan = bmwFactory.createSedanCar();
const bmwSUV = bmwFactory.createSUVCar();
console.log(mercedesSedan.type); // 输出: Mercedes Sedan
console.log(mercedesSUV.type); // 输出: Mercedes SUV
console.log(bmwSedan.type); // 输出: BMW Sedan
console.log(bmwSUV.type); // 输出: BMW SUV

在上述示例中，我们定义了一个抽象工厂类 AbstractCarFactory，它具有创建轿车和 SUV 车的抽象方法。

具体的工厂类 MercedesCarFactory 和 BMWCarFactory 继承自抽象工厂类，并实现了创建奔驰车和宝马车的具体方法。

具体的产品类包括 MercedesSedanCar、MercedesSUVCar、BMWSedanCar 和 BMWSUVCar，它们都具有一个 type 属性用于标识车辆类型。

通过使用抽象工厂模式，我们可以通过具体的工厂类创建一组相关的产品对象，而无需指定具体的类。这样可以实现一组对象的统一管理和创建，并且能够轻松地扩展和修改工厂类和产品类的组合。

建造者模式（Builder Pattern）

将复杂对象的构建过程与其表示分离。它允许使用相同的构建过程来创建不同的表示形式，并且可以逐步构建对象，使得构建过程更加灵活和可控。

下面是一个有一些属性的 Car 类：

class Car{
    #color;
    #fuelType;
    #productionDate;
    constructor(color, fuelType, productionDate) {
        this.#color = color;
        this.#fuelType = fuelType;
        this.#productionDate = productionDate;
    }
    toString(){
        return `car info: color: ${this.#color}, fuelType:${this.#fuelType}, productionDate: ${this.#productionDate}`;
    }
}
const car = new Car('red', 'petrol', new Date('2023-05-01')).toString();
console.log(car); // car info: color: red, fuelType:petrol, productionDate: Mon May 01 2023 08:00:00 GMT+0800 (中国标准时间)

可以看出来，如果要 new 一个 Car，需要记住参数的顺序，虽然这里的属性就 3 个，但是如果有更多属性的对象，就容易混淆。

要为上面的示例创建一个 Builder 类，我们可以这么做：

class CarBuilder{
    #color;
    #fuelType;
    #productionDate;
    setColor(color){
        this.#color = color;
        return this;
    }
    setFuelType(fuelType){
        this.#fuelType = fuelType;
        return this;
    }
    setProductionDate(date){
        this.#productionDate = date;
        return this;
    }
    build(){
        return new Car(this.#color, this.#fuelType, this.#productionDate);
    }
    toString(){
        return `car info: color: ${this.#color}, fuelType:${this.#fuelType}, productionDate: ${this.#productionDate}`;
    }
}
const car1 = new CarBuilder().setColor('yellow').setFuelType('battery').setProductionDate(new Date('2023-06-02'));
const car2 = new CarBuilder().setFuelType('battery').setProductionDate(new Date('2023-06-03')).setColor('blue');
console.log(car1.toString()); // car info: color: yellow, fuelType:battery, productionDate: Fri Jun 02 2023 08:00:00 GMT+0800 (中国标准时间)
console.log(car2.toString()); // car info: color: blue, fuelType:battery, productionDate: Sat Jun 03 2023 08:00:00 GMT+0800 (中国标准时间)

通过链式调用，在设置不同的属性时更容易识别它们，我们更改调用构造器方法的顺序还可以获得相同的结果。

以上是通过链式调用实现构造器模式，执行构造器模式的另一种方法是使用抽象类和具体类。

下面是一个使用抽象类和具体类的建造者模式的示例：

class Car {
  #doors;
  addParts() {
    this.#doors = 4;
  }
  say() {
    console.log(`I am a ${this.#doors}-door car`);
  }
}
class Truck {
  #doors;
  addParts() {
    this.#doors = 2;
  }
  say() {
    console.log(`I am a ${this.#doors}-door truck`);
  }
}
class CarBuilder {
  #car;
  step1() {
    this.#car = new Car();
  }
  step2() {
    this.#car.addParts();
  }
  get() {
    return this.#car;
  }
}
class TruckBuilder {
  #truck;
  step1() {
    this.#truck = new Truck();
  }
  step2() {
    this.#truck.addParts();
  }
  get() {
    return this.#truck;
  }
}
class Shop {
  construct(builder) {
    builder.step1();
    builder.step2();
    return builder.get();
  }
}
const shop = new Shop();
const carBuilder = new CarBuilder();
const truckBuilder = new TruckBuilder();
const car = shop.construct(carBuilder);
const truck = shop.construct(truckBuilder);
car.say(); // I am a 4-door car
truck.say(); // I am a 2-door truck

上面代码中有两个 Builder 类：CarBuilder 和 TruckBuilder，它们有相同的方法，Shop 的 construct 方法接受一个 Builder 实例，然后执行一系列的组装步骤：step1 和 step2。

所以，可以给 Shop 提供不同的 Builder 来控制实际对象构建过程。

原型模式（Prototype Pattern）

在 JavaScript 中，每个对象都有一个原型（prototype），并且可以通过原型来共享属性和方法。原型设计模式通过复制现有对象的原型来创建新的对象，而不是通过使用类或构造函数来创建。

下面是一个使用 Object.create() 方法实现原型模式的示例：

// 原型对象
const carPrototype = {
  color: 'red',
  getColor() {
    console.log(`The car color is ${this.color}`);
  }
};
// 创建新对象并继承原型
const car1 = Object.create(carPrototype);
car1.getColor(); // The car is red
// 自定义新对象的属性和方法
car1.doors = 4;
car1.getDoors = function () {
  console.log(`The car doors is ${this.doors}`);
};
car1.getDoors(); // The car doors is 4
// 创建另一个新对象并继承原型
const car2 = Object.create(carPrototype);
car2.color = 'black';
car2.getColor(); // The car color is black

利用 JavaScript 的原型继承来高效地创建新对象，可以减少内存使用并提高应用程序的性能。

结构型设计模式

代理模式（Proxy Pattern）

提供一个代理对象来控制对另一个对象的访问，代理对象充当了客户端和实际对象之间的中介，从而可以在访问对象之前或之后执行一些额外的操作。

下面是一个代理模式的示例：

class RealSubject {
  request() {
    console.log('RealSubject: Handing request');
  }
}
class ProxySubject {
  constructor(realSubject) {
    this.realSubject = realSubject;
  }
  checkAccess() {
    return true;
  }
  request() {
    if (this.checkAccess()) {
      this.realSubject.request();
    }
  }
}
const realSubject = new RealSubject();
const proxy = new ProxySubject(realSubject);
proxy.request(); // RealSubject: Handing request

使用 ES6 的 Proxy 示例：

const person = {
  name: 'John Doe',
  age: 42,
  nationality: 'American'
};
const personProxy = new Proxy(person, {
  get: (target, prop) => {
    console.log(`The value of ${prop} is ${Reflect.get(target, prop)}`);
  },
  set: (target, prop, value) => {
    console.log(`Changed ${prop} from ${target[prop]} to ${value}`);
    return Reflect.set(target, prop, value);
  }
});
personProxy.name; // The value of name is John Doe
personProxy.age = 43; // Changed age from 42 to 43
personProxy.name = 'Jane Doe'; // Changed name from John Doe to Jane Doe

通过使用 ES6 的 Proxy 对象，我们可以在代理对象上拦截和处理对目标对象的操作。这种方式提供了更灵活的控制和操作对象的能力，并可以用于实现许多不同的代理行为，如数据验证、缓存、日志记录等。

装饰者模式（Decorator Pattern）

在不修改现有对象的情况下，动态地将新功能附加到对象上。通过创建一个装饰者对象，将新功能逐层地包装在原始对象周围，从而扩展其功能。这种方式可以在运行时动态地添加、修改或删除对象的行为。

下面是一个装饰者模式示例：

// 抽象组件
class Coffee {
  getCost() {
    return 10;
  }
  getDescription() {
    return 'Coffee';
  }
}
// 具体组件
class Espresso extends Coffee {
  getCost() {
    return 15;
  }
  getDescription() {
    return 'Espresso';
  }
}
// 抽象装饰者
class CoffeeDecorator extends Coffee {
  constructor(coffee) {
    super();
    this.coffee = coffee;
  }
  getCost() {
    return this.coffee.getCost();
  }
  getDescription() {
    return this.coffee.getDescription();
  }
}
// 具体装饰者
class MilkDecorator extends CoffeeDecorator {
  constructor(coffee) {
    super(coffee);
  }
  getCost() {
    return this.coffee.getCost() + 5;
  }
  getDescription() {
    return `${this.coffee.getDescription()}, Milk`;
  }
}
// 具体装饰者
class SugarDecorator extends CoffeeDecorator {
  constructor(coffee) {
    super(coffee);
  }
  getCost() {
    return this.coffee.getCost() + 2;
  }
  getDescription() {
    return `${this.coffee.getDescription()}, Sugar`;
  }
}
const coffee = new Espresso();
const coffeeWithMilk = new MilkDecorator(coffee);
const coffeeWithMilkAndSugar = new SugarDecorator(coffeeWithMilk);
console.log(coffee.getCost()); // 输出: 15
console.log(coffee.getDescription()); // 输出: Espresso
console.log(coffeeWithMilk.getCost()); // 输出: 20
console.log(coffeeWithMilk.getDescription()); // 输出: Espresso, Milk
console.log(coffeeWithMilkAndSugar.getCost()); // 输出: 22
console.log(coffeeWithMilkAndSugar.getDescription()); // 输出: Espresso, Milk, Sugar

在上述示例中，我们有一个抽象组件 Coffee，它定义了咖啡的基本功能。然后，我们创建了具体组件 Espresso，它是一种具体类型的咖啡。

接下来，我们定义了一个抽象装饰者 CoffeeDecorator，它继承自抽象组件，并持有一个抽象组件的引用。然后，我们创建了两个具体装饰者 MilkDecorator 和 SugarDecorator，它们分别在咖啡上添加了牛奶和糖的额外功能。

我们首先创建了一个具体组件的实例 coffee，然后使用装饰者 MilkDecorator 和 SugarDecorator 逐层包装这个具体组件。最后，我们可以通过调用装饰后的对象的方法来获取添加了额外功能的咖啡的成本和描述信息。

装饰者模式的优势在于它提供了一种灵活的方式来扩展对象的功能,通过组合不同的装饰者，可以动态地添加或移除对象的功能，同时保持代码的可维护性和可扩展性。

适配器模式（Adapter Pattern）

允许将一个类的接口转换为另一个接口，以满足客户端的需求。适配器模式使得原本不兼容的接口能够一起工作。

适配器模式可以用于以下情况：

当我们使用一个已有的对象或类时，发现它的接口与我们的需求不匹配，无法直接使用。
当我们希望复用已有的对象或类，但其接口与我们的系统要求的接口不一致。

下面是一个关于充电器的适配器模式示例：

// 目标接口
class Charger {
  connect() {
    throw new Error("Method 'connect' must be implemented.");
  }
  charge() {
    throw new Error("Method 'charge' must be implemented.");
  }
}
// 原始类
class OldCharger {
  plugIn() {
    console.log('Plugging in old charger.');
  }
  electricCharge() {
    console.log('Charging with old charger.');
  }
}
// 适配器类
class ChargerAdapter extends Charger {
  constructor(oldCharger) {
    super();
    this.oldCharger = oldCharger;
  }
  connect() {
    this.oldCharger.plugIn();
  }
  charge() {
    this.oldCharger.electricCharge();
  }
}
// 客户端代码
function chargeDevice(charger) {
  charger.connect();
  charger.charge();
}
const oldCharger = new OldCharger();
const chargerAdapter = new ChargerAdapter(oldCharger);
chargeDevice(chargerAdapter);
// 输出:
// Plugging in old charger.
// Charging with old charger.

在上述示例中，我们定义了一个目标接口 Charger，其中包含了两个抽象方法 connect 和 charge。

然后，我们创建了一个原始类 OldCharger，它具有两个方法 plugIn 和 electricCharge，但它的接口与目标接口不匹配。

接下来，我们实现了适配器类 ChargerAdapter，它继承自目标接口 Charger，并持有一个原始类的引用。在适配器类中，我们实现了目标接口的方法 connect 和 charge，并在方法中调用原始类的方法进行充电操作。

最后，我们在客户端代码中，创建了原始类的实例 oldCharger，并将其传递给适配器类的构造函数来创建适配器实例 chargerAdapter。通过调用适配器的方法 connect 和 charge，实际上会调用原始类的方法 plugIn 和 electricCharge，从而实现了接口的适配。

桥接模式（Bridge Pattern）

将抽象部分与实现部分分离，使它们可以独立变化。桥接模式的关键思想是将一个大类或多个紧密关联的类分为两个独立的层次结构，从而降低它们之间的耦合性。

桥接模式可以用于以下情况：

当一个类存在多个变化维度时，可以通过桥接模式将这些维度分离，使得它们可以独立变化。

当需要在抽象部分和实现部分之间建立一个稳定的连接，以便能够动态地切换和扩展它们。

下面是一个桥接模式的示例：

// 抽象部分
abstract class Shape {
  protected color: Color;
  constructor(color: Color) {
    this.color = color;
  }
  abstract draw(): string;
}
// 实现部分
interface Color {
  fill(): string;
}
// 具体实现部分
class RedColor implements Color {
  fill() {
    return "red";
  }
}
class BlueColor implements Color {
  fill() {
    return "blue";
  }
}
// 具体抽象部分
class Circle extends Shape {
  constructor(color: Color) {
    super(color);
  }
  draw() {
    return `Drawing a ${this.color.fill()} circle.`;
  }
}
class Square extends Shape {
  constructor(color: Color) {
    super(color);
  }
  draw() {
    return `Drawing a ${this.color.fill()} square.`;
  }
}
// 客户端代码
const redColor: Color = new RedColor();
const blueColor: Color = new BlueColor();
const redCircle: Shape = new Circle(redColor);
const blueSquare: Shape = new Square(blueColor);
console.log(redCircle.draw()); // 输出: Drawing a red circle.
console.log(blueSquare.draw()); // 输出: Drawing a blue square.

在上述示例中，我们定义了两个独立的层次结构：抽象部分（Shape）和实现部分（Color）。

抽象部分包含一个抽象方法 draw，并持有一个实现部分的引用（color）。

实现部分包含一个抽象方法 fill，用于表示不同的颜色。

然后，我们创建了两个具体的实现部分类：RedColor 和 BlueColor，它们分别实现了颜色的填充方法。

接下来，我们创建了两个具体的抽象部分类：Circle 和 Square，它们继承自抽象部分 Shape。这些具体的抽象部分类在绘制时会调用实现部分的方法来获取填充的颜色。

最后，我们在客户端代码中，创建了具体实现部分的实例（redColor 和 blueColor），并将其传递给具体抽象部分类的构造函数来创建具体抽象部分的实例（redCircle 和 blueSquare）。通过调用具体抽象部分的 draw 方法，实际上会调用实现部分的 fill 方法，从而实现了抽象部分和实现部分的桥接。

这个示例展示了桥接模式的一种用法，通过将形状和颜色分离，我们可以在两个维度上独立地扩展它们，而不需要修改现有的代码。这种分离使得我们可以根据需要动态地选择不同的颜色来绘制不同的形状，同时保持代码的可扩展性和灵活性。

外观模式（Facade Pattetn）

提供了一个统一的接口，用于访问复杂子系统中的一组接口。外观模式通过隐藏底层系统的复杂性，简化了客户端与子系统之间的交互，并提供了一个简单而统一的接口。

外观模式可以用于以下情况：

当一个系统或库有多个复杂的子组件，并且希望提供一个简化的接口供客户端使用时。
当需要对底层系统进行解耦，使得客户端不需要了解和直接操作底层组件。

下面是一个外观模式的示例：

// 子系统A
class SubsystemA {
  operationA() {
    return 'Subsystem A operation';
  }
}
// 子系统B
class SubsystemB {
  operationB() {
    return 'Subsystem B operation';
  }
}
// 子系统C
class SubsystemC {
  operationC() {
    return 'Subsystem C operation';
  }
}
// 外观类
class Facade {
  constructor() {
    this.subsystemA = new SubsystemA();
    this.subsystemB = new SubsystemB();
    this.subsystemC = new SubsystemC();
  }
  operation() {
    const resultA = this.subsystemA.operationA();
    const resultB = this.subsystemB.operationB();
    const resultC = this.subsystemC.operationC();
    return `${resultA}\n${resultB}\n${resultC}`;
  }
}
// 客户端代码
const facade = new Facade();
const result = facade.operation();
console.log(result);
// 输出:
// Subsystem A operation
// Subsystem B operation
// Subsystem C operation

在上述示例中，我们有三个子系统：SubsystemA、SubsystemB 和 SubsystemC。每个子系统都有自己的一些操作。

然后，我们定义了一个外观类 Facade，它持有子系统的实例，并提供了一个操作方法 operation。在该方法中，我们调用了子系统的操作，并返回它们的结果。

最后，我们在客户端代码中创建了外观类的实例 facade，并调用了它的 operation 方法。通过外观类，客户端可以使用简单的接口来访问底层复杂子系统的功能，而无需直接与子系统进行交互。

外观模式的优点在于简化了客户端的调用过程，封装了底层复杂性，并提供了一个高层次的接口。这样一来，客户端只需与外观类进行交互，而无需了解底层子系统的细节，从而提高了代码的可读性和可维护性。

组合模式（Composite Pattern）

将对象组织成树形结构，并且能够以相同的方式处理单个对象和组合对象。组合模式允许客户端使用统一的方式处理对象的层次结构，而无需关心对象是单个对象还是组合对象。

组合模式可以用于以下情况：

当有一个对象树结构，且希望以统一的方式处理树中的所有对象。

当希望客户端能够一致地对待单个对象和组合对象，而不需要进行特殊处理。

下面是一个组合模式的示例：

// 定义 ItemNode 类
class ItemNode {
  constructor(name) {
    this.children = []; // 存储子节点的数组
    this.name = name; // 节点名称
  }
  // 添加子节点
  add(child) {
    this.children.push(child);
  }
  // 移除子节点
  remove(child) {
    const index = this.children.indexOf(child);
    if (index !== -1) {
      this.children.splice(index, 1);
    }
  }
  // 获取指定索引的子节点
  getChild(i) {
    return this.children[i];
  }
  // 检查节点是否有子节点
  hasChildren() {
    return this.children.length > 0;
  }
}
// 递归遍历树节点
function traverse(indent, node) {
  console.log(Array(indent).join('--') + node.name); // 打印节点名称，根据缩进级别输出层次结构
  for (let i = 0, len = node.children.length; i < len; i++) {
    traverse(indent + 1, node.getChild(i)); // 递归遍历子节点
  }
}
// 创建树结构并执行遍历
function run() {
  const tree = new ItemNode('root');
  const left = new ItemNode('left');
  const right = new ItemNode('right');
  const leftleft = new ItemNode('leftleft');
  const leftright = new ItemNode('leftright');
  const rightleft = new ItemNode('rightleft');
  const rightright = new ItemNode('rightright');
  tree.add(left);
  tree.add(right);
  tree.remove(right); // 移除并重新添加 right 节点
  tree.add(right);
  left.add(leftleft);
  left.add(leftright);
  right.add(rightleft);
  right.add(rightright);
  traverse(1, tree); // 从根节点开始遍历树
}
run();
// 输出
// root
// --left
// ----leftleft
// ----leftright
// --right
// ----rightleft
// ----rightright

在上述示例中，定义了一个名为 ItemNode 的类，用于表示树节点。每个节点具有一个名称和一个存储子节点的数组。

然后，ItemNode 类提供了几个方法来操作节点。add 方法用于向节点添加子节点，remove 方法用于移除指定的子节点。getChild 方法用于获取指定索引位置的子节点，hasChildren 方法用于检查节点是否具有子节点。

最后，还有一个 traverse 函数，用于递归遍历树节点并打印节点名称。该函数接受两个参数，缩进级别和当前节点，通过递归调用 traverse 函数来遍历子节点。

在 run 函数中，创建了一个根节点 tree，以及其他节点。通过调用 add 方法，构建了一个树结构。最后，调用 traverse 函数，从根节点开始遍历并输出每个节点的名称和层次结构。

这段代码展示了组合模式的应用，通过使用递归结构来管理复杂的树状数据，并提供了一种便捷的方式来操作和遍历树节点。

享元模式（Flyweight Pattern）

用于通过共享对象以减少内存消耗和提高性能。它通过将对象的状态分为内部状态（Intrinsic State）和外部状态（Extrinsic State），并共享内部状态来实现对象的共享。

内部状态是对象的不变部分，可以被多个对象共享，而外部状态是对象的可变部分，需要在运行时通过参数传递给对象。享元模式的目标是通过共享尽可能多的内部状态来减少对象的数量。

下面是一个享元模式示例：

// 定义享元对象
class Flyweight {
  constructor(key) {
    this.key = key;
  }
  operation(extrinsicState) {
    console.log(`Flyweight ${this.key} operation with extrinsic state: ${extrinsicState}`);
  }
}
// 具体享元对象
class ConcreteFlyweight extends Flyweight {
  constructor(key) {
    super(key);
  }
}
// 创建享元工厂
class FlyweightFactory {
  constructor() {
    this.flyweights = {};
  }
  getFlyweight(key) {
    if (!this.flyweights[key]) {
      this.flyweights[key] = new ConcreteFlyweight(key);
    }
    return this.flyweights[key];
  }
  getFlyweightsCount() {
    return Object.keys(this.flyweights).length;
  }
}
// 客户端代码
const factory = new FlyweightFactory();
const flyweight1 = factory.getFlyweight('key1');
flyweight1.operation('state1');
const flyweight2 = factory.getFlyweight('key2');
flyweight2.operation('state2');
const flyweight3 = factory.getFlyweight('key1');
flyweight3.operation('state3');
console.log(`Total flyweights: ${factory.getFlyweightsCount()}`);
// 输出
// Flyweight key1 operation with extrinsic state: state1
// Flyweight key2 operation with extrinsic state: state2
// Flyweight key1 operation with extrinsic state: state3
// Total flyweights: 2

在上面的代码中，Flyweight 是享元对象的抽象类，定义了共享对象的接口。operation 方法是享元对象的操作方法，接受外部状态作为参数。

FlyweightFactory 充当享元工厂，负责创建和管理享元对象。getFlyweight 方法用于获取享元对象，如果对象不存在则创建一个新的享元对象并将其存储在工厂中。getFlyweightsCount 方法用于获取当前创建的享元对象数量。

ConcreteFlyweight 是具体的享元对象类，实现了抽象享元对象的接口。

在客户端代码中，通过享元工厂创建了几个享元对象，并调用它们的 operation 方法来执行操作。注意到对于相同的内部状态（例如，’key1’），只会创建一个享元对象，其他对象将共享同一个实例。最后，通过 getFlyweightsCount 方法获取创建的享元对象数量。

享元模式的核心思想是共享对象以节省内存和提高性能。它适用于需要大量相似对象的场景，通过共享内部状态来减少对象数量，从而节省系统资源。

行为型设计模式

观察者模式（Observer Pattern）

用于在对象之间定义一对多的依赖关系，当一个对象状态发生变化时，所有依赖它的对象都会收到通知并自动更新。

下面是一个观察者模式示例：

// 主题
class Subject {
  constructor() {
    this.observers = [];
  }
  // 添加观察者
  addObserver(observer) {
    this.observers.push(observer);
  }
  // 删除观察者
  removeObserver(observer) {
    const index = this.observers.indexOf(observer);
    if (index !== -1) {
      this.observers.splice(index, 1);
    }
  }
  // 通知观察者
  notify() {
    for (let i = 0; i < this.observers.length; i++) {
      this.observers[i].update();
    }
  }
}
// 观察者
class Observer {
  constructor(name) {
    this.name = name;
  }
  // 更新方法
  update() {
    console.log(`Observer ${this.name} received notification.`);
  }
}
// 客户端代码
const subject = new Subject();
const observer1 = new Observer('Observer 1');
const observer2 = new Observer('Observer 2');
const observer3 = new Observer('Observer 3');
subject.addObserver(observer1);
subject.addObserver(observer2);
subject.addObserver(observer3);
subject.notify();
// Observer Observer 1 received notification.
// Observer Observer 2 received notification.
// Observer Observer 3 received notification.

在上面的代码中，Subject 是主题类，维护了一个观察者数组，并提供了添加观察者、删除观察者和通知观察者的方法。

Observer 是观察者类，每个观察者具有一个名称，并实现了 update 方法来处理接收到的通知。

在客户端代码中，我们创建了一个主题对象 subject，以及三个观察者对象 observer1、observer2 和 observer3。通过调用 addObserver 方法将观察者注册到主题中，然后调用 notify 方法来通知所有观察者。

观察者模式非常有用，特别适用于对象之间存在一对多的依赖关系的情况。它提供了一种松耦合的方式，让主题和观察者之间的关系灵活，并且使得对象之间的通信更加简单和可维护。

模版模式（Template Pattern）

用于定义算法的骨架，将一些步骤的具体实现延迟到子类中。模板模式通过定义一个模板方法，该方法定义了算法的结构，而具体的实现细节由子类来实现。

模板模式的核心思想是通过将通用的算法流程定义在父类中，将具体实现交给子类。这样可以在不改变算法结构的情况下，通过不同的子类来定制具体的步骤实现。

下面是一个模板模式示例：

// 抽象模板类
class Template {
  templateMethod() {
    this.step1();
    this.step2();
    this.step3();
  }
  step1() {
    throw new Error('Abstract method step1() must be overridden.');
  }
  step2() {
    throw new Error('Abstract method step2() must be overridden.');
  }
  step3() {
    throw new Error('Abstract method step3() must be overridden.');
  }
}
// 具体模板类
class ConcreteClass extends Template {
  step1() {
    console.log('ConcreteClass: Step 1');
  }
  step2() {
    console.log('ConcreteClass: Step 2');
  }
  step3() {
    console.log('ConcreteClass: Step 3');
  }
}
// 客户端代码
const concreteClass = new ConcreteClass();
concreteClass.templateMethod();
// ConcreteClass: Step 1
// ConcreteClass: Step 2
// ConcreteClass: Step 3

在上面的代码中，Template 是抽象模板类，它定义了模板方法 templateMethod，该方法定义了算法的结构，包含了一系列的步骤。每个步骤都是抽象方法，由子类来实现具体的细节。

ConcreteClass 是具体模板类，继承自抽象模板类 AbstractClass。它实现了抽象模板类中的抽象方法，并提供了具体的步骤实现。

在客户端代码中，我们创建了一个具体模板类的实例 concreteClass，然后调用它的 templateMethod 方法来执行算法。由于模板方法已经定义了算法的结构，具体步骤的实现会被自动调用。

模板模式的优势在于它提供了一种统一的算法结构，并且能够在不修改模板方法的情况下，通过子类来定制具体的步骤实现。这种设计模式在许多情况下都能简化代码，提高代码的可维护性和扩展性，特别适用于需要共享算法结构但具体实现略有不同的场景。

策略模式（Strategy Pattern）

用于将一组可互换的算法封装成独立的对象，并使它们能够在运行时动态地切换。策略模式将算法的选择与算法的实现分离，使得它们可以独立变化，从而提供了更好的灵活性和可维护性。

下面是一个使用对象实现策略模式的示例：

// 定义策略对象
const strategies = {
  add(a, b) {
    return a + b;
  },
  subtract(a, b) {
    return a - b;
  },
  multiply(a, b) {
    return a * b;
  }
};
// 定义环境对象
class Context {
  constructor(strategy) {
    this.strategy = strategy;
  }
  setStrategy(strategy) {
    this.strategy = strategy;
  }
  executeStrategy(a, b) {
    return this.strategy(a, b);
  }
}
// 使用示例
const context = new Context(strategies.add);
console.log(context.executeStrategy(5, 3)); // 输出: 8
context.setStrategy(strategies.subtract);
console.log(context.executeStrategy(5, 3)); // 输出: 2
context.setStrategy(strategies.multiply);
console.log(context.executeStrategy(5, 3)); // 输出: 15

在上面的代码中，我们定义了一个策略对象 strategies，其中包含了三种算法：add、subtract 和 multiply。每个算法都是一个函数，接收两个参数并返回计算结果。

然后，我们定义了一个环境对象 Context，它接收一个策略作为参数，并通过 executeStrategy 方法来执行算法。setStrategy 方法用于在运行时切换策略。

最后，我们创建了一个 Context 实例，并初始时将 strategies.add 作为策略。然后通过 executeStrategy 方法来执行算法，输出结果。

通过策略模式，我们可以根据不同的需求和条件选择不同的算法来解决问题，而无需修改使用算法的代码。这样可以增强代码的灵活性和可维护性，并将算法的选择与具体的实现分离开来。

职责链模式（Chain of Responsibility Pattern）

允许将请求从一个处理者传递到另一个处理者，直到请求被处理或达到链的末尾。职责链模式解耦了发送者和接收者之间的关系，并允许多个对象都有机会处理请求，将请求的发送和处理解耦，提高了代码的灵活性和可扩展性。

下面是一个使用对象实现职责链模式的示例：

// 定义处理者对象
class Handler {
  constructor() {
    this.nextHandler = null;
  }
  setNextHandler(handler) {
    this.nextHandler = handler;
  }
  handleRequest(request) {
    if (this.canHandleRequest(request)) {
      this.processRequest(request);
    } else if (this.nextHandler) {
      this.nextHandler.handleRequest(request);
    } else {
      console.log('No handler found for the request.');
    }
  }
  canHandleRequest(request) {
    throw new Error('Abstract method canHandleRequest() must be overridden.');
  }
  processRequest(request) {
    throw new Error('Abstract method processRequest() must be overridden.');
  }
}
// 具体处理者对象
class ConcreteHandler1 extends Handler {
  canHandleRequest(request) {
    return request === 'type1';
  }
  processRequest(request) {
    console.log('ConcreteHandler1 is handling the request.');
  }
}
class ConcreteHandler2 extends Handler {
  canHandleRequest(request) {
    return request === 'type2';
  }
  processRequest(request) {
    console.log('ConcreteHandler2 is handling the request.');
  }
}
// 使用示例
const handler1 = new ConcreteHandler1();
const handler2 = new ConcreteHandler2();
handler1.setNextHandler(handler2);
handler1.handleRequest('type1'); // 输出: ConcreteHandler1 is handling the request.
handler1.handleRequest('type2'); // 输出: ConcreteHandler2 is handling the request.
handler1.handleRequest('type3'); // 输出: No handler found for the request.

在上面的代码中，我们定义了一个处理者对象 Handler，它包含了一个指向下一个处理者的引用 nextHandler，以及处理请求的方法 handleRequest。canHandleRequest 方法用于判断处理者是否能够处理特定的请求，processRequest 方法用于处理请求的具体逻辑。

然后，我们定义了两个具体的处理者对象 ConcreteHandler1 和 ConcreteHandler2，它们分别实现了 canHandleRequest 和 processRequest 方法来处理不同类型的请求。

在使用示例中，我们创建了一个 ConcreteHandler1 实例和一个 ConcreteHandler2 实例，并通过 setNextHandler 方法将它们链接在一起形成职责链。然后，我们调用 handleRequest 方法，并传入不同的请求类型，看看每个处理者是否能够处理该请求。

通过职责链模式，我们可以将请求发送方与接收方解耦，并允许多个对象都有机会处理请求。这样可以动态地组织和拓展处理流程，提高代码的灵活性和可维护性。

迭代器模式（Interator Pattern）

用于提供一种统一的方式来遍历集合对象的元素，而不暴露集合对象的内部结构。迭代器模式将遍历操作封装在一个独立的迭代器对象中，使得客户端可以通过迭代器对象逐个访问集合中的元素，而不需要关注底层集合的实现细节。

在 JavaScript 中，迭代器模式通常通过使用迭代器对象来实现。迭代器对象提供了一组标准的方法，如 next、hasNext 等，用于遍历集合并获取元素。

下面是一个迭代器模式的示例：

class Iterator {
  constructor(collection) {
    this.collection = collection;
    this.index = 0;
  }
  next() {
    return this.collection[this.index++];
  }
  hasNext() {
    return this.index < this.collection.length;
  }
}
// 使用示例
const names = ['Alice', 'Bob', 'Charlie', 'Dave'];
const iterator = new Iterator(names);
while (iterator.hasNext()) {
  console.log(iterator.next());
}
// 输出：
// Alice
// Bob
// Charlie
// Dave

在上面的示例中，我们定义了一个 Iterator 类作为迭代器对象。该类接收一个集合对象作为参数，并在构造函数中初始化了当前索引 index。

迭代器对象提供了两个方法：next 方法用于获取集合中的下一个元素，hasNext 方法用于检查是否还有下一个元素。

在使用示例中，我们创建了一个名为 names 的字符串数组，并创建了一个迭代器对象 iterator，将该数组传递给迭代器的构造函数。

然后，我们使用 while 循环和迭代器的 hasNext 方法来遍历集合，并使用 next 方法逐个获取集合中的元素，并将其打印出来。

迭代器模式使得集合对象和迭代逻辑的实现分离，提供了一种统一的方式来遍历集合。它增强了代码的可读性和可维护性，并允许在不改变集合结构的情况下，通过修改迭代器对象来改变遍历行为。

状态模式（State Pattern）

用于根据对象的内部状态改变其行为。状态模式将对象的行为封装在不同的状态类中，并使用一个上下文对象来管理状态的切换。

在 JavaScript 中，状态模式通常使用对象和多态性来实现。

下面是一个订单状态模式的示例：

// 抽象订单状态类
class OrderState {
  constructor(order) {
    this.order = order;
  }
  pay() {
    throw new Error('pay() must be implemented.');
  }
  ship() {
    throw new Error('ship() must be implemented.');
  }
  complete() {
    throw new Error('complete() must be implemented.');
  }
}
class CompletedState extends OrderState {
  // 可以不实现任何方法，表示订单已完成且没有更改的操作
}
class ShippedState extends OrderState {
  complete() {
    console.log('Order is completed.');
    this.order.setState(new CompletedState(this.order));
  }
}
class PaidState extends OrderState {
  ship() {
    console.log('Order is shipped.');
    this.order.setState(new ShippedState(this.order));
  }
}
// 具体订单状态类
class PendingPaymentState extends OrderState {
  pay() {
    console.log('Payment received. Order is now paid.');
    this.order.setState(new PaidState(this.order));
  }
}
// 订单类
class Order {
  constructor() {
    this.state = new PendingPaymentState(this);
  }
  setState(state) {
    this.state = state;
  }
  pay() {
    this.state.pay();
  }
  ship() {
    this.state.ship();
  }
  complete() {
    this.state.complete();
  }
}
// 使用示例
const order = new Order();
order.pay(); // 输出: Payment received. Order is now paid.
order.ship(); // 输出: Order is shipped.
order.complete(); // 输出: Order is completed.

在上面的示例中，我们模拟了一个订单管理系统，订单类 Order 包含了状态对象，并提供了支付（pay）、发货（ship）和完成（complete）等方法，这些方法会委托给当前状态对象进行处理。

我们定义了抽象的订单状态类 OrderState，其中包含了共同的方法。然后，我们创建了具体的订单状态类，如待支付状态（PendingPaymentState）、已支付状态（PaidState）、已发货状态（ShippedState）和已完成状态（CompletedState），它们分别继承自抽象状态类并实现了相应的行为。

在使用示例中，我们创建了一个订单对象 order，初始状态为待支付。然后依次调用支付、发货和完成方法，订单对象会委托给当前状态对象进行处理，并根据当前状态执行相应的行为。

这个示例展示了状态模式在订单管理系统中的应用。通过状态模式，可以根据订单的不同状态，实现不同的行为，并且可以灵活地添加新的状态和相关行为，而不需要修改订单类的代码。这提供了更好的可维护性、可扩展性和灵活性，同时避免了大量的条件语句和代码重复。

访问者模式（Visitor Pattern）

用于将数据结构与其上的操作解耦，使得操作可以独立变化而不影响数据结构。它通过在数据结构中引入一个访问者对象，让访问者对象在不修改数据结构的情况下，定义新的操作并应用于数据结构中的元素。

下面是一个访问者模式的示例：

// 元素类
class Element {
  accept(visitor) {
    throw new Error('accept() must be implemented.');
  }
}
// 具体元素类
class ConcreteElementA extends Element {
  accept(visitor) {
    visitor.visitElementA(this);
  }
  operationA() {
    console.log('Operation A performed on ConcreteElementA.');
  }
}
class ConcreteElementB extends Element {
  accept(visitor) {
    visitor.visitElementB(this);
  }
  operationB() {
    console.log('Operation B performed on ConcreteElementB.');
  }
}
// 访问者类
class Visitor {
  visitElementA(element) {
    throw new Error('visitElementA() must be implemented.');
  }
  visitElementB(element) {
    throw new Error('visitElementB() must be implemented.');
  }
}
// 具体访问者类
class ConcreteVisitor extends Visitor {
  visitElementA(element) {
    element.operationA();
  }
  visitElementB(element) {
    element.operationB();
  }
}
// 使用示例
const elements = [new ConcreteElementA(), new ConcreteElementB()];
const visitor = new ConcreteVisitor();
elements.forEach(element => {
  element.accept(visitor);
});
// 输出
// Operation A performed on ConcreteElementA.
// Operation B performed on ConcreteElementB.

在上面的示例中，我们定义了一个抽象元素类 Element，其中包含了一个抽象方法 accept，用于接受访问者对象。具体元素类 ConcreteElementA 和 ConcreteElementB 继承自抽象元素类，并实现了 accept 方法。

访问者类 Visitor 定义了访问者对象的接口，其中包含了访问具体元素的方法 visitElementA 和 visitElementB。

具体访问者类 ConcreteVisitor 继承自访问者类，并实现了访问具体元素的方法，这些方法在访问具体元素时执行相应的操作。

在使用示例中，我们创建了一个包含具体元素的数组 elements，以及一个具体访问者对象 visitor。

然后，我们使用 forEach 循环遍历元素数组，并调用元素的 accept 方法，将访问者对象应用于元素。元素根据接受的访问者对象，调用相应的访问者方法。

输出结果显示了访问者模式的工作原理。访问者对象可以访问不同类型的元素，并根据元素类型执行相应的操作。通过访问者模式，我们可以将数据结构与操作进行解耦，使得操作可以独立变化，并且可以方便地添加新的操作，而无需修改元素类的代码。

访问者模式适用于处理复杂的数据结构，其中元素类型较多且经常变化，同时操作类型也较多且可能频繁变化的情况。它提供了一种灵活和可扩展的方式来处理复杂的数据结构，同时遵循开闭原则，使得增加新的操作或元素类型更加方便。

备忘录模式（Memento Pattern）

用于捕捉对象的内部状态并在之后恢复到该状态，而无需暴露对象的实现细节。备忘录模式允许你将对象的状态封装到备忘录对象中，并在需要时进行保存和恢复。

下面是一个备忘录模式的示例：

// 备忘录对象类
class Memento {
  constructor(state) {
    this.state = state;
  }
  getState() {
    return this.state;
  }
}
// 原始对象类
class Originator {
  constructor() {
    this.state = null;
  }
  setState(state) {
    this.state = state;
  }
  getState() {
    return this.state;
  }
  createMemento() {
    return new Memento(this.state);
  }
  restoreMemento(memento) {
    this.state = memento.getState();
  }
}
// 管理者类
class Caretaker {
  constructor() {
    this.mementos = [];
  }
  addMemento(memento) {
    this.mementos.push(memento);
  }
  getMemento(index) {
    return this.mementos[index];
  }
}
// 使用示例
const originator = new Originator();
const caretaker = new Caretaker();
// 设置初始状态
originator.setState('State 1');
console.log('Current state:', originator.getState());
// 创建备忘录并保存状态
const memento1 = originator.createMemento();
caretaker.addMemento(memento1);
// 修改状态
originator.setState('State 2');
console.log('Current state:', originator.getState());
// 创建备忘录并保存状态
const memento2 = originator.createMemento();
caretaker.addMemento(memento2);
// 恢复到第一个备忘录的状态
originator.restoreMemento(caretaker.getMemento(0));
console.log('Restored state:', originator.getState());
// 输出
// Current state: State 1
// Current state: State 2
// Restored state: State 1

在上面的示例中，我们定义了备忘录对象类 Memento 用于存储原始对象的状态，原始对象类 Originator，它包含了状态的设置和获取方法，以及创建备忘录和恢复状态的方法。

管理者类 Caretaker 用于管理备忘录对象，它可以添加备忘录并获取指定索引的备忘录。

在使用示例中，我们创建了原始对象 originator 和管理者对象 caretaker。

首先，我们设置初始状态并打印当前状态。

然后，我们创建一个备忘录对象 memento1，将原始对象的状态保存到备忘录中，并将备忘录添加到管理者中。

接着，我们修改状态为 “State 2” 并打印当前状态。

然后，我们创建另一个备忘录对象 memento2，保存当前状态，并将备忘录添加到管理者中。

最后，我们从管理者中获取第一个备忘录，并使用 restoreMemento 方法将状态恢复到该备忘录的状态，然后打印恢复后的状态。

原始对象可以创建备忘录并将其保存到管理者中，备忘录对象存储了原始对象的状态。当需要恢复到之前的状态时，可以从管理者中获取相应的备忘录，并使用原始对象的 restoreMemento 方法将状态恢复到备忘录中保存的状态。

备忘录模式提供了一种简单且有效的方式来实现对象的状态保存和恢复。它将状态的保存和恢复操作封装在备忘录对象中，使得原始对象不需要暴露其内部细节。备忘录模式提供了一种可靠的机制来管理对象的状态历史，并支持撤销和恢复操作。

命令模式（Command Pattern）

用于将请求封装成对象，使得可以将请求的发送者与接收者解耦。它将请求的操作封装在命令对象中，并将其作为参数传递给调用者，调用者通过执行命令对象来触发请求的执行。

下面是一个命令模式的示例：

// 命令接口
class Command {
  execute() {
    throw new Error("execute() must be implemented.");
  }
}
// 具体命令类
class ConcreteCommandA extends Command {
  constructor(receiver) {
    super();
    this.receiver = receiver;
  }
  execute() {
    this.receiver.actionA();
  }
}
class ConcreteCommandB extends Command {
  constructor(receiver) {
    super();
    this.receiver = receiver;
  }
  execute() {
    this.receiver.actionB();
  }
}
// 接收者类
class Receiver {
  actionA() {
    console.log("Receiver: Action A executed.");
  }
  actionB() {
    console.log("Receiver: Action B executed.");
  }
}
// 调用者类
class Invoker {
  constructor() {
    this.commands = [];
  }
  addCommand(command) {
    this.commands.push(command);
  }
  executeCommands() {
    this.commands.forEach((command) => {
      command.execute();
    });
    this.commands = [];
  }
}
// 使用示例
const receiver = new Receiver();
const invoker = new Invoker();
const commandA = new ConcreteCommandA(receiver);
const commandB = new ConcreteCommandB(receiver);
invoker.addCommand(commandA);
invoker.addCommand(commandB);
invoker.executeCommands();
// 输出
// Receiver: Action A executed.
// Receiver: Action B executed.

在上面的示例中，我们定义了一个命令接口 Command，其中包含了一个抽象的执行方法 execute。

具体命令类 ConcreteCommandA 和 ConcreteCommandB 继承自命令接口，并实现了 execute 方法。这些具体命令类持有一个接收者对象 Receiver 的引用，并在执行方法中调用接收者的相应方法。

接收者类 Receiver 包含了具体的操作方法，如 actionA 和 actionB。

调用者类 Invoker 负责管理命令对象，它可以添加命令到命令列表中，并通过执行命令列表来触发请求的执行。

在使用示例中，我们创建了一个接收者对象 receiver 和调用者对象 invoker。

然后，我们创建了具体命令对象 commandA 和 commandB，并将接收者对象传递给它们。

接下来，我们将命令对象添加到调用者的命令列表中，并调用 executeCommands 方法来执行命令列表中的所有命令。

命令对象封装了具体的操作和接收者，并通过调用者来触发请求的执行。通过使用命令模式，可以将请求的发送者与接收者解耦，同时可以方便地扩展和组合不同的命令，而不需要修改调用者的代码。

命令模式适用于需要将请求和操作进行解耦的场景。它提供了一种灵活的方式来设计和组织代码，同时支持撤销和重做操作。命令模式还可以用于实现日志和事务处理等功能。

解释器模式（Interpreter Pattern）

定义了一种语言的文法表示，并使用解释器来解释执行这些语法结构。解释器模式通过将语法规则表示为对象，并提供解释方法来执行这些对象，使得可以根据特定的语法规则解析和执行复杂的表达式或语言。

下面是一个解释器模式的示例，用于解释和计算简单的数学表达式：

// 抽象表达式类
class Expression {
  interpret() {
    throw new Error('interpret() must be implemented.');
  }
}
// 终结符表达式类
class NumberExpression extends Expression {
  constructor(value) {
    super();
    this.value = value;
  }
  interpret() {
    return this.value;
  }
}
// 非终结符表达式类
class AddExpression extends Expression {
  constructor(leftExpression, rightExpression) {
    super();
    this.leftExpression = leftExpression;
    this.rightExpression = rightExpression;
  }
  interpret() {
    return this.leftExpression.interpret() + this.rightExpression.interpret();
  }
}
// 上下文类
class Context {
  constructor() {
    this.expressionStack = [];
  }
  pushExpression(expression) {
    this.expressionStack.push(expression);
  }
  popExpression() {
    return this.expressionStack.pop();
  }
}
// 使用示例
const context = new Context();
const expression1 = new NumberExpression(10);
const expression2 = new NumberExpression(5);
const expression3 = new NumberExpression(2);
const addExpression = new AddExpression(expression1, expression2);
const finalExpression = new AddExpression(addExpression, expression3);
context.pushExpression(finalExpression);
const result = context.popExpression().interpret();
console.log('Result:', result); // 输出: Result: 17

在上述示例中，我们定义了几个关键的类：

Expression 是抽象表达式类，定义了 interpret 方法。
NumberExpression 是终结符表达式类，表示一个数字。
AddExpression 是非终结符表达式类，表示两个表达式的相加操作。
Context 是上下文类，用于存储表达式的执行上下文。

在示例中，我们创建了一些数字表达式对象和相加表达式对象，并将它们组合成一个复杂的表达式树。然后，我们将最终的表达式对象推入上下文中，并通过解释器模式执行该表达式。最终，我们得到了计算结果并将其打印出来。

中介模式（Mediator Pattern）

用于降低多个对象之间的直接通信，通过引入一个中介者对象来协调对象之间的交互。中介者模式促进了对象之间的解耦，使得它们可以独立地改变和复用。

下面是一个中介模式的示例，用于协调多个同事对象之间的通信：

// 中介者
class Mediator {
  constructor() {
    this.colleagues = [];
  }
  addColleague(colleague) {
    this.colleagues.push(colleague);
  }
  sendMessage(message, sender) {
    for (const colleague of this.colleagues) {
      if (colleague !== sender) {
        colleague.receiveMessage(message);
      }
    }
  }
}
// 同事对象
class Colleague {
  constructor(name, mediator) {
    this.name = name;
    this.mediator = mediator;
  }
  sendMessage(message) {
    this.mediator.sendMessage(message, this);
  }
  receiveMessage(message) {
    console.log(`${this.name} received message: ${message}`);
  }
}
// 使用示例
const mediator = new Mediator();
const colleague1 = new Colleague("Colleague 1", mediator);
const colleague2 = new Colleague("Colleague 2", mediator);
const colleague3 = new Colleague("Colleague 3", mediator);
mediator.addColleague(colleague1);
mediator.addColleague(colleague2);
mediator.addColleague(colleague3);
colleague1.sendMessage("Hello, everyone!"); // 输出: Colleague 2 received message: Hello, everyone!，Colleague 3 received message: Hello, everyone!
colleague2.sendMessage("How are you?"); // 输出: Colleague 1 received message: How are you?，Colleague 3 received message: How are you?
colleague3.sendMessage("Nice to meet you!"); // 输出: Colleague 1 received message: Nice to meet you!，Colleague 2 received message: Nice to meet you!

在上述示例中，我们创建了一个中介者对象 Mediator 和多个同事对象 Colleague。

中介者负责管理同事对象之间的通信，它维护了一个同事对象的列表，并提供了添加同事对象和发送消息的方法。

同事对象可以通过调用中介者的 sendMessage 方法来发送消息，而不需要直接与其他同事对象进行通信。

当一个同事对象发送消息时，中介者会接收到该消息并根据需要的逻辑将消息转发给其他同事对象。

通过使用中介者模式，我们可以将对象之间的通信逻辑集中管理，降低了对象之间的耦合性，并提供了更灵活和可扩展的设计。这种模式常用于需要协调和管理多个对象之间复杂交互的场景。

总结

JavaScript 的设计模式对于开发人员来说具有许多重要的作用，总结如下：

提供解决方案：设计模式为常见的软件设计问题提供了经过验证和可行的解决方案。通过学习和掌握设计模式，开发人员可以更快速、更有效地解决问题，避免从头开始设计和实现复杂的解决方案。
代码复用和可维护性：设计模式鼓励代码的模块化和组件化，使得代码更具可重用性。通过使用设计模式，开发人员可以将通用的功能封装成可复用的模块，并在不同的项目中重复使用，从而减少重复代码的编写。此外，设计模式还提供了一种结构化的方式来组织代码，使得代码更易于理解和维护。
可扩展性和灵活性：设计模式通过将系统的各个部分解耦，降低了组件之间的依赖性，使得系统更具可扩展性和灵活性。通过使用设计模式，可以轻松地添加、修改或替换系统中的组件，而无需修改其他部分的代码。
促进团队协作：设计模式提供了一种共享的设计和通信语言，使得团队成员之间可以更好地理解和沟通。团队成员熟悉设计模式可以更快地理解代码，提高协作效率，减少沟通成本。
最佳实践指南：设计模式代表了一些经过验证的最佳实践，它们是从实际项目和经验中总结出来的。学习和遵循设计模式可以帮助开发人员遵循一些最佳实践，提高代码的质量和可维护性，减少错误和bug的出现。

综上所述，熟悉 JavaScript 的设计模式对于开发人员来说非常重要。它们提供了一种通用的解决方案和最佳实践，可以提高代码的可复用性、可维护性和可扩展性，促进团队协作，帮助开发人员更高效地解决问题和编写高质量的代码。

参考
JavaScript Design Patterns - Dofactory
JavaScript Patterns Workshop | JavaScript Patterns
Patterns.dev - Modern Web App Design Patterns

浏览器中跨标签页通信

2026-04-28T09:30:01Z

前言

Web 应用程序通常有时候需要打开多个标签页同时使用，在某些情况下，我们可能希望在多个标签页之间共享数据或同步状态。例如，当用户在一个标签页中进行某项操作时，我们可能希望在其他相关的标签页能够及时更新以反映这些变化。但是，这些标签页之间如何进行通信呢？在本文中，我们将探索浏览器中的不同窗口、标签页或 iframe 下的不同文档之间相互通信。

示例代码： Cross-Tab Communication

在线运行： Cross-Tab Communication

演示：

1. LocalStorage

写入数据

使用 localStorage.setItem(key, value) 方法将数据存储到 LocalStorage 中：

  localStorage.setItem(
    STORAGE_KEY,
    `${new Date().toLocaleString()} from page: ${id}: ${input.value}`
  );

监听数据变化

通过监听 LocalStorage 的 storage 事件来检测数据的变化，并进行相应的处理：

window.addEventListener('storage', (e) => {
  if (e.key === STORAGE_KEY) {
    creatMessageElement(e.newValue);
  }
});

e 指的是 StorageEvent，有以下几个特有的只读属性：

属性名	描述
`key`	该属性代表被修改的键值。当被 clear() 方法清除之后该属性值为 null。
`newValue`	该属性代表修改后的新值。当被 clear() 方法清理后或者该键值对被移除，`newValue` 的值为 `null` 。
`oldValue`	该属性代表修改前的原值。在设置新键值对时由于没有原始值，该属性值为 `null`。
`storageArea`	被操作的 storage 对象。
`url`	key 发生改变的对象所在文档的 URL 地址。

storage 事件仅在 不同标签页间 的 LocalStorage 数据变化 时才会触发，同一标签页内的LocalStorage 变化不会触发该事件，所以上面的写入数据和监听数据变化代码可以写在同一个页面中，并不会陷入死循环。

需要注意的是，LocalStorage 的大小限制通常在 5MB 左右，而且数据存储在本地，可能会受到 安全性 的影响。因此，在使用 LocalStorage 进行跨标签页通信时，应注意数据的大小和安全性问题。

2. BroadcastChannel

BroadcastChannel 用于在不同标签页之间广播消息。它使用类似于广播电台的模式，发送者将消息广播到所有订阅该频道的标签页，该频道在同源下的所有浏览器上下文共用，一个名称只对应一个频道。

以下是一个简单的示例代码：

// 创建一个监听“channel-name”频道的新频道
const channel = new BroadcastChannel('channel-name');
const buttonFun = () => {
  // 发送消息
  channel.postMessage(
    `${new Date().toLocaleString()} from page: ${id}: ${input.value}`
  );
};
// 监听频道 message 事件，频道收到消息时触发 message 事件
channel.addEventListener('message', (e) => {
  creatMessageElement(e.data);
});
window.onbeforeunload = () => {
  // 断开与频道的连接
  channel.close();
};

3. SharedWorker

使用 Web Workers，可以在后台线程中运行 JavaScript。这样做的好处是可以在独立线程中执行费时的处理任务，渲染主线程不会被阻塞。在 worker 内，不能直接操作 DOM 节点，也不能使用 window 对象的默认方法和属性。然而你可以使用大量 window 对象之下的东西，包括 WebSockets，IndexedDB 以及 FireFox OS 专用的 Data Store API 等数据存储机制。

Web Workers 分为两种：

专用线程 Dedicated worker

一个专用 worker 仅能被生成它的脚本所使用，也就是只能在当前窗口当前页面使用。
共享线程 Shared worker

一个共享 worker 可以被多个脚本使用，即使这些脚本正在被不同的 window、iframe 或者 worker 访问，所以 SharedWorker 允许不同标签页之间共享一个后台线程，从而实现数据和消息的共享。

SharedWorker 使用语法：

new SharedWorker(URL, name|options);

参数

URL
worker 将执行的脚本URL，必须是同源。
name (可选)
worker 的名称标识，主要用于调试。
options（可选）
创建实例时设定的可选属性的对象，可用的属性包括：
- type: worker 类型，可设定的值为 classic 或者 module. 若不指定，默认值为 classic。
- credentials: 一个指定要用于工作程序的凭据类型，可设定的值为 omit、same-origin 或 include。 若不指定，或者 type 设定为 classic, 默认值为 omit （无需凭据）。
- name： worker 的名称标识，主要用于调试。

以下是一个简单的示例代码：

if (!!window.SharedWorker) {
  const myWorker = new SharedWorker('./worker.js', 'share-worker-name');
  const buttonFun = () => {
    const message = `${new Date().toLocaleString()} from page: ${id}: ${
      input.value
    }`;
    // 发送消息
    myWorker.port.postMessage(message);
  };
  // 监听消息
  myWorker.port.onmessage = (e) => {
    creatMessageElement(e.data);
  };
  // 关闭窗口时
  window.onbeforeunload = () => {
    myWorker.port.postMessage('CLOSE');
  };
} else {
  alert('Your browser does not support SharedWorker');
}

worker.js 这个文件会被多个页面加载，但却可以共享数据，类似于 单例模式，虽然使用了 new 操作符，但最后获取到的数据却是一样的。

// 所有页面共享的数据
const listOfPort = [];
onconnect = (e) => {
  // port 属性返回一个用于通信和控制共享 worker 的 MessagePort 对象
  const port = e.ports[0];
  // 如果当前页面不存在该 port 则加到列表中
  if (!listOfPort.includes(port)) {
    listOfPort.push(port);
  }
  // 监听返回的消息
  port.onmessage = (e) => {
    const data = e.data;
    // 窗口关闭时删除该窗口的 port
    if (data === 'CLOSE') {
      const portIndex = listOfPort.findIndex((p) => p === port);
      if (portIndex > -1) {
        listOfPort.splice(portIndex, 1);
        return;
      }
    }
    // 过滤掉当前页面的 port，不给自己发送消息
    listOfPort.filter((p) => p !== port).forEach((p) => p.postMessage(data));
  };
  // 如果使用  port.addEventListener('message',()=>{}) 方式监听则需要使用 start 来启动。
  // port.start();
};

如果 worker 中使用 console.log() 将不会被打印在当前窗口的 console 中。
以 chrome 为例，需要在 chrome://inspect/#service-workers 中点击 inspect 打开的开发者工具才会打印 worker 中的 console，如下图所示：

4. window.open + window.opener

当我们使用 window.open 打开页面时，将返回一个被打开页面 window 的引用。被打开的页面可以通过 window.opener 获取到打开它的页面的引用，通过这种方式我们就将这些页面建立起联系。

以下是一个简单的示例代码：

// 点击按钮通过新窗口打开页面，并收集打开过的页面的window对象
openButton.addEventListener('click', (e) => {
  const otherWindow = window.open(`${url}/WindowOpen/WindowOpen.html`);
  listOfOtherWindows.push(otherWindow);
});
const buttonFun = () => {
  const mseegae = `${new Date().toLocaleString()} from page: ${id}: ${
    input.value
  }`;
  // 过滤掉已关闭的窗口，给未关闭的窗口发送消息
  listOfOtherWindows
    .filter((window) => !window.closed)
    .forEach((window) => window.postMessage(mseegae, url));
  // 给打开该窗口的窗口发送消息
  if (!!window.opener) {
    window.opener.postMessage(mseegae, url);
  }
};
window.addEventListener('message', (e) => {
  if (e.origin === url) {
    creatMessageElement(e.data);
  }
});

显然，这种强关联模式存在一个问题：如果页面不是通过在另一个页面内的 window.open 打开（例直接在地址栏输入），那这个联系就被打破了。

5. WebSocket

WebSocket 是一种在浏览器和服务器之间建立持久连接的协议，可以实现双向通信。通过WebSocket，我们可以在不同的标签页之间进行实时的数据传输和通信。

在跨标签通信方面，我们可以在每个标签页中都创建一个 WebSocket 连接，并通过 WebSocket 发送和接收消息。当一个标签页发送消息时，其他标签页可以通过监听 WebSocket 事件来接收消息，并做出相应的处理。

以下是一个简单的示例代码：

const ws = new WebSocket(WS_SERVER);
const buttonFun = () => {
  const message = `${new Date().toLocaleString()} from page: ${id}: ${
    input.value
  }`;
  ws.send(JSON.stringify({ id, message }));
};
ws.onmessage = (e) => {
  const data = JSON.parse(e.data);
  if (data.id !== id) {
    creatMessageElement(data.message);
  }
};

浏览器兼容性

浏览器兼容性最低版本：

API	Chrome	Edge	Safari	Firefox	Opera	IE
LocalStorage	4	12	4	3.5	11.5	8
BroadcastChannel	54	79	15.4	38	41	不支持
SharedWorker	5	79	5-6.1, 16	29	11.5	不支持
window.open	4	12	3.1	2	10	6
WebSocket	5	12	5	7	12.1	10

优缺点

API	跨域	优点	缺点
LocalStorage	不支持	1.支持存储和共享数据	1.需要数据存储在本地，可能会受到安全性的影响 2.不适用于实时通信，只能通过事件监听来传递数据
BroadcastChannel	不支持	1.支持实时通信，可以广播消息给所有订阅者	1.需要浏览器支持，不适用于老旧浏览器
SharedWorker	不支持	1.支持多个标签页共享同一个后台线程，实现数据和消息的共享 2.不会占用渲染主线程	1.需要额外的开发工作，包括在后台线程中处理消息和同步数据
window.open	支持	1.适用于各种浏览器，不受兼容性限制。	1.需要从当前窗口打开另一个窗口
WebSocket	支持	1.支持实时双向通信，可以在不同标签页之间进行消息传递	1.需要服务器端的支持来处理 WebSocket 连接

总结

我们讨论了五种浏览器跨标签通信方法，选择合适的方法取决于具体需求和场景。如果仅需要实时通信使用 BroadcastChannel 通信是一个不错的选择，如果需要存储数据和共享数据，且不需要实时通信，可以使用 LocalStorage，对于需要复杂的协调工作和高性能的应用程序，Shared Web Workers 可能更适合，如果需要支持跨域，且仅在该窗口打开另一个窗口的情况下，适合使用 window.open + window.opener，如果有 WebSocket 服务端的支持，使用 WebSocket 实现实时通信和双向数据传递。

通过这些方法，我们可以在不同的标签页之间进行数据传递和实时通信。根据具体的需求和场景，选择适合的方法来实现跨标签通信。

参考
Web Workers API | MDN
Broadcast Channel API | MDN

浏览器渲染原理

2026-05-02T14:29:17Z

前言

浏览器渲染原理是网页开发中重要的基础知识之一，了解浏览器的渲染过程，可以帮助我们更好地优化网页性能，提升用户体验。

浏览器渲染引擎

浏览器渲染引擎是浏览器中最核心的部分。它负责将 HTML、CSS、JavaScript 等网页元素转换成可视化的页面，我们称之为文档对象模型（DOM）。渲染引擎将这些元素解析、计算、布局、绘制等等，最终呈现在屏幕上。

不同浏览器使用不同的渲染引擎。例如，Google Chrome 使用 Blink 渲染引擎，Firefox 使用 Gecko 渲染引擎，Safari 使用 WebKit 渲染引擎等等。这些渲染引擎可能会有不同的实现方式，但它们的目标都是相同的：将网页元素转换成可视化的页面。

浏览器渲染流程

下面我们将详细介绍浏览器的渲染流程。通常来说，浏览器渲染流程包括以下几个步骤：

1. 解析 HTML

当浏览器向服务器获取 HTML 文档的请求时，服务器返回二进制流格式的 HTML 页面，响应头 Content-Type 值为 text/html，这里 text/html 是 MIME 类型，它告诉浏览器它是一个 HTML 文档。

当浏览器收到 HTML 数据时，主线程开始解析文本字符串（HTML）并将其转换为文档对象模型（DOM），在浏览器开发者工具 console 中输入 document 即可看到一个完整的 DOM 树结构。

当 HTML 解析器发现 <script> 标签时，会暂停 HTML 文档的解析，并必须加载、解析和执行JavaScript代码，即<script> 标签会阻塞 DOM 的解析和渲染。

<link>标签不会阻塞 DOM 的解析，但是会阻塞 DOM 的渲染，同时还会阻塞之后的 <script> 标签的执行。

<link rel="preload"> preload 属性会预加载资源。
<link rel="dns-prefetch"> dns-prefetch 属性 (DNS 预获取) 是尝试在请求资源之前解析域名，仅对跨域域上的 DNS 查找有效。

2. 样式计算（Style）

主线程解析 CSS 并确定每个 DOM 节点的计算样式，目的是为了计算出 DOM 节点中每个元素的具体样式。经过计算，每个元素节点都会有一个最终样式，在浏览器开发者工具 Elements -> Computed 即可查看。

样式计算主要有以下三个步骤：

2.1 把 CSS 转换为 styleSheets

CSS 样式主要来源：

<link> 标签
<style> 标签
元素的 Style 属性

浏览器无法直接理解纯文本的CSS样式，当渲染引擎接收到 CSS 文本时，会将 CSS 文本转换为浏览器可以理解的 styleSheets 结构。

在浏览器开发者工具 console 中输入 document.styleSheets 即可看到所有解析后 CSS 样式。

如果不提供任何 CSS，也会有默认样式。如 <h1> 标签显示大于 <h2> 标签，这是因为浏览器具有默认样式表。如果你想知道 Chrome 的默认 CSS 是什么样的，你可以在这里看到源代码。

2.2 标准化样式表中的属性值

body { font-size: 2em }
p { color: blue }
span { display: none }
div { font-weight: bold }
div p { color: green }
div { color: red }

可以看到上面的 CSS 文本中有很多属性值，如 2em、blue、bold，这些属性值不被渲染引擎理解，需要将所有值转换为渲染引擎容易理解的、标准化的计算值，这个过程就是属性值标准化。
如 2em 被解析成 32px，red 被解析成了 rgb(255, 0, 0)，bold 被解析为 700。

2.3 计算出每个 DOM 节点的具体样式

每个 DOM 节点的样式属性，是 CSS 继承规则和层叠规则进行叠加计算的结果。层叠是 CSS 的一个基本特征，继承指的是某些样式属性会从父元素传递给子元素，而层叠则是指当多个样式规则应用到同一个元素时，浏览器根据一定的规则确定最终的样式值。

3. 布局（Layout）

现在，我们知道文档的结构和每个节点的样式，但这还不足以显示页面，因为我们还不知道 DOM 元素的几何位置信息。

布局阶段是浏览器确定每个元素在页面中的位置和大小的过程。在布局过程中，浏览器会根据元素的盒模型、样式属性等计算出每个元素的位置和尺寸。

Chrome 在布局阶段需要完成两个任务：创建布局树和布局计算。

3.1 创建布局树

遍历 DOM 树中的每一个节点，过滤不可见的元素（比如 head 标签，比如具有 display:none 样式的元素），将所有的可见元素构建一棵只包含可见元素布局树（具有 visibility: hidden 的元素会在布局树中）。

3.2 布局计算

有了布局树之后，就需要对布局树中各节点的几何坐标位置进行计算，其中包含 x，y 坐标和边界框大小等信息。

4. 分层（Layer）

主线程遍历布局树，根据策略对布局树进行分层，并生成一棵对应的图层树。Chrome 引入了分层和合成的机制就是为了提升每帧的渲染效率。

在浏览器开发者工具（Layers）可以查看可视化页面的分层情况，如下图所示：

什么样的节点会创建独立的图层？

display 属性值为 fixed 或者 sticky
opacity 属性值小于 1
z-index 属性值不为 auto
transform、filter、perspective、clip-path 属性值不为 none
在 will-change 中指定了任意CSS属性

5. 绘制（Paint）

有了图层树后，主线程会为每个图层单独绘制指令集，用于描述这一层的内容该如何画出来。如把画笔移到某个位置，先画什么再画什么，把一个图层的绘制拆分成很多小的绘制指令，然后再把这些指令按照顺序组成一个待绘制列表。

主线程将每个图层的绘制信息提交给合成线程(compositor thread) ，剩余工作将由合成线程完成。

6. 分块（Tiling）

浏览器渲染分块用于将页面分割为多个独立的块，然后分别渲染这些块。每个块都是独立的渲染区域，并且可以单独更新和绘制，以提高渲染性能和响应速度。

页面分割：浏览器将页面划分为多个独立的块。通常，这些块的大小是固定的，例如 256x256 像素。每个块都有自己的位置和尺寸。

多线程处理：浏览器可以使用多个线程来并行处理分块。这使得浏览器能够更高效地利用硬件资源。

7. 光栅化（Raster）

光栅化是将页面上的图形、文本和其他可见元素转换为像素的过程。在浏览器中，页面的可视内容通常以矢量形式表示，但在显示器上呈现时需要将其转换为光栅图像（由像素组成的位图）。

合成线程将分块信息交给 GPU 进程，GPU 进程会开启多个线程来完成光栅化，并且优先处理靠近视口区域的块，将块生成位图。

8. 画（Draw）

合成线程拿到每个图层、块的位图后，生产一个个 指引(quad) 信息，指引会标识出每个位图应该画在屏幕的哪个位置，以及会考虑旋转，缩放等变形。

变形发生在合成线程，与渲染主线程无关，所以这就是 transform 效率高的本质原因。

重排（reflow）

reflow 的本质是重新计算 layout 树，以下的操作都会导致页面 reflow ：

页面首次渲染。
浏览器窗口大小发生变化。
元素的内容发生变化。
元素的尺寸或者位置发生变化。
元素的字体大小发生变化。
激活 CSS 伪类。
查询某些属性或者调用某些方法。
添加或者删除可见的 DOM 元素。

为了避免连续的多次操作导致布局树反复计算，浏览器会合并这些操作，当 JS 代码全部完成后再进行计算，所以改动属性造成的 reflow 是异常完成，也因此当 JS 获取布局属性时，可能无法获取到最新的布局信息。

浏览器在反复权衡下，最终决定获取属性立即 reflow。如调用 dom.clientWidth。

重绘（repaint）

repaint 的本质就是重新根据分层信息计算绘制指令，以下的操作会导致 repaint：

改变 color、background 相关属性：background-color、background-image。
改变 outline 相关属性：outline-color、outline-width 、text-decoration。
改变 border-radius、visibility、box-shadow。

当改动了可见样式后，就需要重新计算，会引发 repaint。

元素的布局信息也属于可见样式，所以 reflow 一定会引起 repaint。

为什么 transform 效率高

因为 transform 既不会影响布局也不会影响绘制指令，它只会影响渲染流程的最后一步 draw 阶段，由于 draw 在合成线程中，所以 transform 的变化几乎不会影响到渲染主线程。

总结

在本文中，我们介绍了浏览器的渲染过程，包括文档解析、样式计算、布局、分层、绘制和合成等步骤。我们还介绍 reflow 和 repaint。以及 transform 效率，这些可以帮助我们优化网页性能，为用户带来更好的浏览体验。

参考：

Inside look at modern web browser (part 3)

How Blink works

How browser rendering works — behind the scenes

How the browser renders a web page? — DOM, CSSOM, and Rendering

浏览器原理系列-浏览器渲染流程详解

浏览器事件循环

2026-04-30T22:54:24Z

1.事件循环的概念

JavaScript 是一种单线程语言，意味着它只有一个主线程，它运行在浏览器的渲染主线程中，渲染主线程承担着很多的工作，渲染页面、执行 JS 都在其中运行。这意味着如果我们在渲染主线程上执行了一个长时间的任务，那么 UI 将被锁定，无法响应用户的任何操作。为了避免这种情况发生，我们需要使用事件循环。

2.JS为何会阻碍页面渲染

以这段 Html 为例：

<h1 id="text">Hi there, I'm Chaomin Ruan</h1>
<button id="change-text-button">change text</button>
<script>
  var text = document.querySelector('#text');
  var button = document.querySelector('#change-text-button');
  var delay = (duration) => {
  var start = Date.now();
    while (Date.now() - start < duration) {};
  };
  button.addEventListener('click',()=>{
    text.textContent = '嘿，你好，我是阮超民';
    delay(3000);
 });
</script>

有一句文本和一个按钮，点击按钮时先改变文本内容，然后延迟3秒。
但实际是3秒后文本才会变化。

Hi there, I’m Chaomin Ruan

试一试:

点击按钮： (点击后观察上方文字)

这是因为 JS 执行与 Paint 任务都发生在渲染主线程，Paint 任务没有及时执行，即绘制列表没有及时提交给合成线程。

3.同步和异步

事件循环的基本思想是将任务分为两类：同步和异步任务和异步任务。同步任务在主线程上执行，而异步任务（网络请求，定时器、事件监听等）交给其他线程去处理，自身立即结束任务的执行，转而执行后续代码，当其他线程完成时，将事先传递的回调函数包装成任务，加入到消息队列的末尾排队，等待主线程调度执行。这允许主线程继续执行其他任务，而不必等待长时间运行的任务完成。

在这种异步模式下，浏览器永不阻塞，从而最大限度的保证了单线程的流畅运行。

4.处理模型

HTML事件循环处理模型大致可以这样描述:

while (true) {
    const taskStartTime = performance.now();
    // It's unspecified where UI events fit in. Should each have their own task?
    const task = eventQueue.pop();
    if (task)
        task.run();
    if (performance.now() - taskStartTime > 50)
        reportLongTask();
    if (!hasRenderingOpportunity())
        continue;
    invokeAnimationFrameCallbacks();
    while (needsStyleAndLayout()) {
        styleAndLayout();
        invokeResizeObservers();
    }
    markPaintTiming();
    render();
}

事件循环不是 JavaScript 引擎的一部分，而是浏览器运行时中的一个组件，它使用单个执行线程不断异步等待下一条消息在某个时刻进入队列，如图所示

详细步骤如下：

1、所有同步任务都在主线程上执行，形成一个调用栈

2、主线程之外，还存在一个”消息队列”。只要异步任务执行完成，就到消息队列中排队

3、一旦调用栈中的所有同步任务执行完毕，系统就会按次序读取消息队列中的异步任务，于是被读取的异步任务结束等待状态，进入执行栈，开始执行

4、主线程不断重复上面的第三步

5.任务有优先级吗

任务没有优先级，在消息队列中是一个 FIFO（先进先出）的队列。

但消息队列是有优先级的

根据 W3C 的最新解释:

每个任务都有一个任务类型，同一个类型的任务必须在一个任务队列，不同类型的任务可以分属于不同的队列。
在一次事件循环中，浏览器可以根据实际情况从不同的队列中取出任务执行。
但微任务队列中的任务优先所有其他任务执行，一旦调用栈变空，微任务就会被执行。

随着浏览器的复杂度急剧提升，W3C 不再使用宏队列的说法

在目前 chrome 的实现中，至少包含了下面的队列：

延时队列：用于存放定时器到达后的回调任务，优先级「中」
交互队列：用于存放用户操作后产生的事件处理任务，优先级「高」
微队列：用户存放需要最快执行的任务，优先级「最高」

添加任务到微队列的主要方式主要是使用 Promise、MutationObserver

6.代码片段

demo1

console.log('script start');
setTimeout(function () {
  console.log('setTimeout');
}, 0);
Promise.resolve()
  .then(function () {
    console.log('promise1');
  })
  .then(function () {
    console.log('promise2');
  });
console.log('script end');

日志的输出顺序会是什么呢？

试一试:

输出的结果是：script start, script end, promise1, promise2, setTimeout

为什么会这样？我们来一步步分析（点击箭头试一试）：

分析：

console.log(‘script start’);
setTimeout(function () {
  console.log(‘setTimeout’);
}, 0);
Promise.resolve()
  .then(function () {
    console.log(‘promise1’);
  })
  .then(function () {
    console.log(‘promise2’);
  });
console.log(‘script end’);

Tasks	Run script setTimeout callback
Microtasks	Promise then Promise then
JS stack
Log	script start script end promise1 promise2 setTimeout

demo2

有 2 个 div，一个 div 里面嵌着另一个 div

<div class="outer">
  <div class="inner"></div>
</div>

给定下面的JS，如果点击里面的 div.inner 会输出什么?


// Let's get hold of those elements
var outer = document.querySelector('.outer');
var inner = document.querySelector('.inner');
// Let's listen for attribute changes on the
// outer element
new MutationObserver(function () {
  console.log('mutate');
}).observe(outer, {
  attributes: true,
});
// Here's a click listener…
function onClick() {
  console.log('click');
  setTimeout(function () {
    console.log('timeout');
  }, 0);
  Promise.resolve().then(function () {
    console.log('promise');
  });
  outer.setAttribute('data-random', Math.random());
}
// …which we'll attach to both elements
inner.addEventListener('click', onClick);
outer.addEventListener('click', onClick);

试一试:

点击内部方块触发点击事件:

输出的结果是：click, promise, mutate, click, promise, mutate, timeout, timeout

“点击” 事件是一个任务。Mutation observer 和promise callbacks 是作为微任务排队的。setTimeout 回调作为一个任务排队。所以，事情是这样的：

分析：

// Let’s get hold of those elements
var outer = document.querySelector(‘.outer’);
var inner = document.querySelector(‘.inner’);
// Let’s listen for attribute changes on the
// outer element
new MutationObserver(function () {
  console.log(‘mutate’);
}).observe(outer, {
  attributes: true,
});
// Here’s a click listener…
function onClick() {
  console.log(‘click’);
  setTimeout(function () {
    console.log(‘timeout’);
   }, 0);
  Promise.resolve().then(function () {
    console.log(‘promise’);
  });
  outer.setAttribute(‘data-random’,   Math.random());
}
// …which we’ll attach to both elements
inner.addEventListener(‘click’, onClick);
outer.addEventListener(‘click’, onClick);

Tasks	Dispatch click setTimeout callback setTimeout callback
Microtasks	Promise then Mutation observers Promise then Mutation observers
JS stack
Log	click promise mutate click promise mutate timeout timeout

因为事件冒泡，点击内部的 div，也会触发外部 div 的点击事件，外部的 div 再调用回调函数，但内部 div 的 setTimerout 并未被执行，所以，也验证了上面第 5 点所说的，交互任务的优先级高于定时任务。

7.总结

本文介绍了浏览器事件循环的概念、原理和工作流程。了解了同步和异步，任务的优先级，并通过代码片断来验证任务执行顺序。

事件循环又叫做消息循环，是浏览器渲染主线程的工作方式。单线程是异步产生的原因，事件循环是异步的实现方式。

在 Chrome 的源码中，它开启一个不会结束的 for 循环，每次循环从消息队列中取出第一个任务执行，而其他线程只需要在合适的时候将任务加入到队列末尾即可。

过去把消息队列简单分为宏队列和微队列，这种说法目前已无法满足复杂的浏览器环境，取而代之的是一种更加灵活多变的处理方式。

根据 W3C 官方的解释，每个任务有不同的类型，同类型的任务必须在同一个队列，不同的任务可以属于不同的队列。不同任务队列有不同的优先级，在一次事件循环中，由浏览器自行决定取哪一个队列的任务。但浏览器必须有一个微队列，微队列的任务一定具有最高的优先级，必须优先调度执行。

对于Web开发人员来说，深入了解浏览器事件循环机制是非常重要的。只有通过合理的异步编程技术和对 JavaScript 引擎的理解，才能写出高效、健壮的 Web 应用程序。

参考：

Browser Event loop: micro and macro tasks, call stack, render queue: layout, paint, composite

JavaScript Event Loop And Call Stack Explained

Tasks, microtasks, queues and schedules

使用 GitHub REST API 将博客同步到 GitHub

2026-05-02T08:31:09Z

前言

在写博客的过程中，往往一篇博客都会经过几次修改，将每次修改的地方产生一个历史版本可以做对比，现在很多的记笔记软件都有历史版本这个功能，如果自己去开发这个功能稍微会有点麻烦，就想到了 GitHub，在博客修改或发布时同步到 GitHub，在 GitHub 上查看历史版本，同时作为远程备份。

效果

REST 介绍

REST（Representational State Transfer，表现层状态转换）是一个架构风格、设计风格，它没有一个明确的标准，只是提供了一个架构的设计原则。如果一个架构符合 REST 原则，就称它为 RESTful 架构。它首次出现在 2000 年 Roy Thomas Fielding 的博士论文中，在论文中提到：”我这篇文章的写作目的，就是想在符合架构原理的前提下，理解和评估以网络为基础的应用软件的架构设计，得到一个功能强、性能好、适宜通信的架构。”

GitHub REST API

GitHub REST API 是典型的 REST 风格的 web API，它几乎支持一切的 GitHub 操作，如基本的创建 repository、提交、搜索、发布 issue、删库跑路等等。

例如获取某个用户的公开可用信息

Get a user 获取某个用户的公开可用信息，如用户的ID、name、email、注册时间等等。

每个 API 官网文档都详细的介绍了参数、HTTP响应状态码等，并且有 CURL、JavaScript、GitHub CLI 的代码示例，我们使用 Postman 来试一试：

可以看见成功获取到了我的 GitHub 账号的一些信息。

同步博客

我的博客服务端是使用 JAVA 开发，调用 GitHub REST API 是通过服务端来调用，当然了也可以在前端使用官方代码示例中的 Octokit.js 来调用。

主要使用 GitHub REST 中的 Repository contents API ，此 API 可以在仓库中创建、修改和删除 Base64 编码的内容。此 API 需要验证账号权限。

1.权限认证 Authentication

有两种方法可以对 GitHub REST API进行身份验证。在某些地方，需要身份验证的请求将返回404 Not Found，而不是 403 Forbidden。这是为了防止私有存储库意外泄露给未经授权的用户。

Basic authentication

$ curl -u username:token https://api.github.com/user

OAuth2 token (sent in a header)

$ curl -H "Authorization: Bearer OAUTH-TOKEN" https://api.github.com
//在大多数情况下，可以使用 Authorization: Bearer 或 Authorization: token 传递令牌。 但是，如果要传递 JSON Web 令牌 (JWT)，则必须使用 Authorization: Bearer。

2.创建 Token

创建个人访问令牌 token 来代替账号密码，如何创建可以参考官方介绍：Create a PAT
令牌的作用域权限只需要 repo 就够了，生成后的令牌只会显示一次！

3.创建文件内容

请求方法：PUT
请求路径：https://api.github.com/repos/用户名/仓库名/contents/文件路径
JSON参数：

{
  "message": "commit message",// 提交的信息
  "content": "aGVsbG8gd29ybGQgIQ==" // 文件内容，Base64编码
}

Example:

创建成功：

此 API 需要 Token 才能访问，在 Headers 中加上 Authorization

4.更新文件内容

更新比创建多一个sha参数，就是上面创建成功之后返回的sha

请求方法：PUT
请求路径：https://api.github.com/repos/用户名/仓库名/contents/文件路径
JSON参数：

{
  "message": "update message",// 提交信息
  "content": "aGVsbG8gd29ybGQgIQoK5L2g5aW977yB",// 文件内容，Base64编码
  "sha":"c52e00fbdd1730341db890f4c1bc23b492601870" // 创建成功时 API 返回的 sha
}

Example:

更新成功：

5.删除文件

请求方法：DELETE
请求路径：https://api.github.com/repos/用户名/仓库名/contents/文件路径
JSON参数：

{
  "message": "delete message",// 提交信息
  "sha":"14d773b65db1d8aacafd7050444822b08fd04ae6"// 创建或者更新时 API 返回的 sha
}

Example:

删除成功：

6.总结

以上就是对使用 GitHub REST API 对仓库内容进行创建、修改、删除操作的说明，GitHub 的提交记录：

参考：

GitHub REST API

Hello World!

2026-04-26T23:35:02Z

前言

由于疫情原因，今年没有回老家过年，这也是第一次在杭州过年。
终于有时间把我的个人网站重构，于是从大年初一开始了我的开发计划。经过两个月的努力，第一版本终于上线了！

技术栈

前端前台 Angular、TypeScript、Rxjs
前端后台 Angular、TypeScript、Rxjs、NG-ZORRO、Editor.md
后端服务 Spring Boot、Spring Security、JWT、MyBatis-Plus
数据库 MySQL

后台管理添加文章界面

为什么写博客

1. 记录

记录，成为更好的自己。人生中有太多美好或深刻的瞬间，无论是学到的新知识还是生活点滴，许久之后，再翻看自己曾经写过的文章，一定会感觉到自己的点滴变化和进步。

2. 分享

写博客的过程其实也是分享自己学习收获的过程，在学习的过程和日常的开发中，难免会遇到一些问题，也要去网络寻找答案，所以知识只有分享才有存在的价值！

3. 讨论

大家一起讨论问题，或赞同，或反对，听听别人的想法，可以在交流中成长。

总结

对于一个程序员来说，写博客可以记录自己的成长经历，加深对技术点的理解，结交更多志同道合的朋友，在自己进步的同时，帮助他人。