在 Front-matter 区域添加 sticky 字段可以设定文章的置顶与置底，亦可以设置文章的排列顺序

这个功能是 hexo-generator-index 插件所提供的

具体文档在这里

将 sticky 设置为 true 或者大于 1 的数字，可以设置置顶

将 sticky 设置为 -1 可以设置置底

文章隐藏

如果有一些文章只想记录不想发布在网站上，可以使用hexo-hide-posts插件

在 Front-matter 中设置 hidden 属性为 true 即可

文档在这里

视频标签

一直用 video 标签插入视频，但是每次都要写好麻烦，而且不同浏览器的原生 video 标签样式是不同的

于是找到了 hexo-tag-dplayer 这个插件，用法很简单：

1

{% dplayer url="" key=value ... %}

hideToggle 标签

有时候想要隐藏一些内容，手动点击才打开

1
2

{% hideToggle 点我打开 %}
{% endhideToggle %}

更多标签

butterfly.org 文档

时间：2025 年 8 月 14 日 夜晚

内容基本都是聊天记录直接搬过来的

回顾工作经历，得到从小白到专业的思考

我过去的人生里，大学毕业之前都是在完成社会基础任务。这是社会框架下每个人都必须做的事情

学历是这个框架下的层次证明，是综合了性格、家族条件、童年印象等过程的结果，是很难改变的事情。但是完成了这个任务之后。我并没有工作和收入

然而真正进入现在的行业，我大概花了不到一年的时间，在这个行业上花了不到五年左右的时间。我从一个几乎是外行的人，进入到知名企业，可以独当一面完成项目，应该称得上是专业的程度

在专科+函授本科的起点上。一个行业外的人 -> 决定了一个方向 -> 花时间学习社会接轨的知识 -> 进入行业五年 -> 达到专业的水平

五年的时间并不长，人的职业生涯至少有 30 年，六个五年。也就是说，行动力最强的情况下，我还有至少五次的机会去尝试新的技能，并且达到专业水平…..

人们总是说在一个行业深耕十年二十年，能成为大牛。但实际上更多是成为了“老油条”

还有些感叹… 人熟练一份普通的工作真的很快，从入行到瓶颈，只有三五年的时间

所以说不定… 职业生涯上做一个突破性的决定，进入新的行业，并不是坏事。1+1 往往是大于 2 的

进入行业的困境和一点学习交流的幻想

我缺少一个突破性的决定和一个学习的途径

我需要一个导师

认真的讲，说不定未来有一天，我们（聊天记录里指白船，实际上并非只有 QQ 群）真的可以交换技能，把其他人带进自己的行业，让自己进入其他人的行业

比如我花三个月的时间跟帆哥学习市场销售，或者一些户外用品店的常识性技能，或者帆哥内推我进入他的部门，从最基础的做起。逐渐熟悉零售行业的管理方式行业规则

再比如我找林克学习单片机，林克可以找我学习 web。互相学技能的时间也不会超过三个月，只要有不错的作品，就可以打败 70% 的竞争者

我知道这是很理想化，很不稳定的假设。但是也是一种可能性

当做一件事情时间久了腻掉了。互相就是导师

粗糙的规划

在职业生涯中，我认为最困难的事情是入行。只要解决了这个问题，在行业里一定是能发展的

就拿我自己来说，我的学历就是我在任何行业里的天花板。

如何让自己的未来更精彩，更多样，我觉得方法是在饿不死的情况下尝试更多的事情….

我应该在现在这份工作上积累资源，同时寻找契机

未来尝试其他类型的工作时，不能带有焦虑情绪。而是类似“开启新的生活方式”这种憧憬和挑战的心态

资源就是钱和人，契机就是运气和意愿

钱可以让我不焦虑，焦虑就会草率决定生活和工作

人是互补技能的导师

运气就是帆哥在招人但是招不到靠谱的，但我就很靠谱（×

愿望就是需要我的时候，我刚好可以做这种工作

我不会为了让自己变强而变学习

我会为了新鲜的事情和理想的生活状态而探索

我觉得人的存在目的不是为了单纯的“向上走”或者“进步”，而是随着自己的变化，不断做出各种尝试去接近理想的生活方式

我要成为华子姐那样自由奔放的社会人士 ——《mono 女孩》

• 服务器（运行机器人等物理设备）
• 机器人账号和登录状态（提供运行环境和 Api）
• Api：OneBot 等（提供与机器人框架对接的方式以及功能开发接口）
• 机器人框架：Koishi，Nonebot，Mirai 等

Koishi

Koishi 是一个开源的跨平台机器人框架

Koishi 的意思是古明地恋，东方 Project 中的角色

docker 部署一个对接 qq 的机器人

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

version: "3"

services:
  bot:
    container_name: koishi
    # 如果服务器性能不佳，或者确认完全不需要puppeteer功能，那么可以不安装chromium
    # https://koishi.chat/zh-CN/manual/starter/docker.html#%E5%90%AF%E5%8A%A8%E5%AE%B9%E5%99%A8
    image: docker.1ms.run/koishijs/koishi
    restart: unless-stopped
    volumes:
      - ./koishi-data:/koishi
    environment:
      - TZ=Asia/Shanghai
    network_mode: host
    # ports:
    #   - "5140:5140"

  qq:
    container_name: llonebot
    image: docker.1ms.run/initialencounter/llonebot:latest
    privileged: true
    restart: unless-stopped
    environment:
      - VNC_PASSWD=llonebotpass
    network_mode: host
    # ports:
    #   - "7081:7081" # login
    #   - "3000:3000" # http
    #   - "3001:3001" # ws

聊天机器人的控制台

docker 服务成功运行后，浏览器访问云服务器的 5140 端口，可以看到控制台

控制台提供了对 bot 的所有管理能力，比如运行状态，插件安装卸载，日志等

安装插件

相关文档：安装和配置插件

插件系统是 Koishi 的核心，bot 所有的功能都来自于插件

Koishi 的插件是以”koishi-plugin-“开头的 npm 包，安装插件的过程实际上也是安装了一个 npm 包

由于 Koishi 官方插件市场镜像长期没有更新，可以使用官方插件提供的社区镜像源

进入插件配置，找到分组：console 下的 market（插件市场本身也是插件，可以在插件配置中修改）

可以看到说明中会提供几个社区镜像，选择一个填入 search.endpoint 就可以了

因为现在 Koishi 控制台部署在公网上，任何人都可以通过 ip:5140 访问到控制台，会有安全隐患

现在尝试在控制台种安装auth插件，这个插件可以给控制台提供用户和密码登录的功能

在插件市场里搜索auth，安装后进入插件配置页面

进入auth的插件配置，设置密码，点击右上角的三角形按钮启用插件

至此，完成了一次插件的安装和配置，以及控制台的密码登录设置

koishi 的插件大致可以分为以下几类：

• 适配器（adapter），用来对接不同的 IM 平台或者 API 协议，如 qq、telegram、onebot 等
• 控制台（console）增强控制台功能的插件，如 auth 等
• 服务类，不直接在聊天中体现，但是给其他插件添加依赖，如 puppeteer，mysql，webdav 等
• 功能类，直接在聊天中体现，如 翻译、图片搜索、天气查询等

对接 qq

登录 qq（llonebot）

在终端中输入 docker logs llonebot 可以获取二维码，用手机 qq 扫描后就可以登录

登录后，使用 vnc 连接到服务器地址的 7081 端口，输入密码llonebotpassword，可以对 docker 中的 qq 进行设置

这里我用的是 NxShell 进行 vnc 连接

设置 ws 反向监听地址（不设置也没问题，可以在适配器里设置正向 ws 监听。不同的适配器会要求不同的监听方式）

连接 onebot

配置 adapter-onebot

启用插件之后，会发现控制台右下角变绿，并出现上下行流量的变化。表示已经配置成功，koishi 平台已经与 qq 建立联系

排错

如果是首次设置，可以进入依赖管理中更新官方插件版本

如果是连接问题，则需要考虑 qq 是否在有 llonebot 的客户端中登录，以及对接的 ip 和端口是否正确

如果是功能性插件出现错误，可以在控制台中查看日志

koishi 的插件的可用性和安全性并不可靠，有些甚至需要去查看源码，安装的时候需要仔细甄别

使用插件市场里的插件丰富 bot 的功能

接下来就可以进入插件市场挑选自己想加入的插件

在论坛中可以找到有趣的推荐，以及一些问题的解决方式

Koishi 论坛

开发自己的插件

插件市场虽然很丰富，但是很难完全满足自己的定制化需求，这个时候就需要自己开发插件了

插件开发文档

创建一个本地的 koishi 插件开发环境

1
2
3
4

yarn create koishi

yarn dev

在工作区创建插件

1

yarn setup [name]

为插件添加依赖

1

yarn workspace koishi-plugin-[name] add [...deps]

koishi 的开发工作区默认是 monorepo 的结构，创建好的插件在 external 文件夹下

1
2
3
4
5
6
7
8

root
├── external
│   └── example
│       ├── src
│       │   └── index.ts
│       └── package.json
├── koishi.yml
└── package.json

开发完成后，可以把插件发布到插件市场上

在发布之前，为插件的 package.json 补充信息，所补充的信息会在插件市场中展示

其中比较值得注意的是 koishi 字段，这个字段会影响到插件配置页面的展示以及其所依赖的其他服务

在 koishi.service 中可以声明此插件所依赖的服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

{
  "name": "koishi-plugin-example",
  "version": "1.0.0",
  "contributors": [
    // 贡献者
    "Alice <alice@gmail.com>",
    "Bob <bob@gmail.com>"
  ],
  "license": "MIT", // 许可证
  "homepage": "https://example.com", // 主页
  "repository": {
    // 源码仓库
    "type": "git",
    "url": "git+https://github.com/alice/koishi-plugin-example.git"
  },
  "keywords": ["example"], // 关键词
  "peerDependencies": {
    "koishi": "^4.3.2"
  },
  "koishi": {
    "description": {
      // 不同语言的插件描述
      "en": "English Description",
      "zh": "中文描述"
    },
    "service": {
      "required": ["database"], // 必需的服务
      "optional": ["assets"], // 可选的服务
      "implements": ["dialogue"] // 实现的服务
    }
  }
}

获取表情图并存到云盘的插件

动机和期望

由于 qq 和微信的某次更新，无法直接保存其他人发送的表情包，所以我就想把自己的表情图独立于平台，保存到自己的网盘上，可以在任何设备任何软件上使用。

可以说是盗图的终极方案

期望

我想象中的这个插件的用法大概是这样的：

1. 我看到了一张表情图，摩拳擦掌想塞进自己的口袋
2. 我把这张表情图发给 bot，（用指令）告诉 bot，把这张图片存下来
3. bot 获取到这张图片，并且对图片做统一处理（尺寸，质量，格式）
4. 将处理好的图片保存在云盘上，云盘同步设备文件夹。
5. 使用的时候直接选择图片发送，图片不会被放大，动画效果不会丢失
6. 可以存官方表情图，也可以存自己的表情图

实现方式

通过引用消息告诉 bot 要存哪张图片：session.quote.elements

1
2
3
4
5
6
7
8

quote.elements.forEach((el) => {
  if (el.type === "img") {
    images.push(el.attrs as ImageElement);
  }
  if (el.type === "mface") {
    mfaces.push(el.attrs as MfaceElement);
  }
});

注册指令，然后在控制台中配置别名，增加参数可以指定存储到云盘的某个子文件夹

1
2
3
4
5
6
7

ctx
  .command("save-sticker <folder:text>", "获取表情包", {
    // @ts-ignore-next-line
    hidden: true, // 隐藏指令，不会在help指令中被发送
    captureQuote: false, // 运行指令避免捕获引用内容 https://github.com/koishijs/koishi/issues/1432
  })
  .alias("盗图", "保存图片");

使用 webdav 的方式连接云盘（坚果云），并将图片上传到云盘

1
2
3
4
5
6
7
8
9
10
11
12

// 引入纯ESM包
async function loadWebDAV() {
  const webdav = await import("webdav");
  console.log(webdav);
  return webdav;
}
const { createClient } = await loadWebDAV();
// 创建webdav客户端
const webdavClient = createClient(webDavUrl, {
  username: ctx.config.webdavUsername,
  password: ctx.config.webdavPassword,
});

将图片处理成特定格式，默认 gif，并且将宽度固定到 300px，提供两个配置项，可以在控制台中配置

为什么要处理成 gif 和 300px

1. 透明度：gif 可以保留表情图的透明度，同时不会变黑（经测试 png 会出现背景变黑的问题，qq 应该不支持 png 的复杂透明度）
2. gif 是官方表情包（mface）的格式
3. gif 支持动图
4. 300 像素是比较通用的尺寸，发送后不会被放大，不太清楚 qq 和微信识别表情包的逻辑，经过尝试得到的结果

最终效果

代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223

import { type Context, Random, Schema, Session } from "koishi";
import sharp from "sharp";
import { imageSize } from "image-size";
async function loadWebDAV() {
  const webdav = await import("webdav");
  console.log(webdav);
  // 这里可以使用 webdav
  return webdav;
}
async function loadImageType() {
  const imageType = await import("image-type");
  console.log(imageType);
  return imageType.default;
}

export const name = "webdav-stickers";
export const usage = `
### 你这图很不错，可惜下一秒就是我的了！

这个插件可以把你看上的表情图片保存到支持 WebDAV 的云盘上，通过云盘，你可以将图片分享给其他朋友，或者同步到自己的其他设备上。

<a href="https://oss.homu.space/imgs/2569b559fd71d9a8af6435c729b6d283.jpg" target="_blank">使用效果</a>

使用方法：
1. 从支持 WebDAV 的云盘（如坚果云等）获取 WebDAV 地址和授权密码，并设置一个存放图片的根目录
2. 配置允许使用该插件的用户
3. 为命令[设置别名](/commands/save-sticker)
4. 把表情图发送给bot可以接收到的地方。引用表情图，使用命令

---

特性：
- 支持批量保存和动图保存
- 静态图片统一使用了png格式（支持透明背景）
- 可设置表情包的最大宽度，避免了表情包尺寸很大的情况
- 支持保存mface表情（官方表情图片）
- 可以通过 folder 参数，将表情图保存到云盘的不同文件夹中

`;

export const inject = ["http"];
export interface Config {
  webdavUrl: string;
  webdavUsername: string;
  webdavPassword: string;
  rootFolder: string;
  allowUsers: string[];
  // triggerWords: string[];
  successMessage: string[];
  stickerWidth: number;
  staticImageFormat: "png" | "gif" | "jpg";
}

interface ImageElement {
  file: string; // 文件名
  fileSize: string; // 文件大小
  src: string; // 文件地址
  subType: string; // 文件类型
}

interface MfaceElement {
  emojiId: string;
  emojiPackageId: string;
  key: string;
  summary: string;
  url: string;
}

export const Config: Schema<Config> = Schema.intersect([
  Schema.object({
    webdavUrl: Schema.string().required().description("WebDAV 服务器地址"),
    webdavUsername: Schema.string().required().description("WebDAV 用户名"),
    webdavPassword: Schema.string()
      .role("secret")
      .required()
      .description("WebDAV 授权密码"),
    rootFolder: Schema.string()
      .default("Stickers")
      .description("设定一个存放图片的根目录"),
  }).description("WebDAV 配置"),
  Schema.object({
    allowUsers: Schema.array(Schema.string())
      .required()
      .description("允许使用该插件的用户（qq号）"),
    successMessage: Schema.array(Schema.string())
      .default(["搞定！"])
      .description("获取成功后的消息"),
  }).description("用户配置"),
  Schema.object({
    stickerWidth: Schema.number()
      .default(300)
      .description("表情包的宽度，默认300px，超过尺寸的静态图片会被压缩"),
    staticImageFormat: Schema.union(["png", "gif", "jpg"])
      .default("gif")
      .description("静态图片的格式，默认gif，不会处理mface"),
  }).description("图片配置"),
]);

export async function apply(ctx: Context) {
  const { createClient } = await loadWebDAV();
  const imageType = await loadImageType();
  ctx.logger.info("成功加载 imageType 和 webdav");
  const webDavUrl = ctx.config.webdavUrl.endsWith("/")
    ? ctx.config.webdavUrl
    : ctx.config.webdavUrl + "/" + ctx.config.rootFolder;
  ctx.logger.info("webDavUrl: " + webDavUrl);
  const webdavClient = createClient(webDavUrl, {
    username: ctx.config.webdavUsername,
    password: ctx.config.webdavPassword,
  });

  async function saveImage(image: ImageElement, folder?: string) {
    if (folder && !(await webdavClient.exists(`/${folder}`))) {
      await webdavClient.createDirectory(`/${folder}`);
    }
    let buffer = await ctx.http.get(image.src);

    // 检测文件是否是gif
    const fileType = await imageType(buffer);
    ctx.logger.info(`文件类型: ${fileType.ext}`);
    let filename: string;

    if (fileType.ext === "gif") {
      filename = `${Date.now()}.gif`;
    } else {
      filename = `${Date.now()}.${ctx.config.staticImageFormat}`;
      const size = imageSize(new Uint8Array(buffer));
      if (size.width > ctx.config.stickerWidth) {
        buffer = await sharp(buffer)
          .resize({ width: ctx.config.stickerWidth })
          .toFormat(ctx.config.staticImageFormat)
          .toBuffer();
      } else {
        buffer = await sharp(buffer)
          .toFormat(ctx.config.staticImageFormat)
          .toBuffer();
      }
    }

    // 如果图片大于设定大小，并且不是gif，则压缩
    const savePath = `${folder ? folder + "/" : ""}${filename}`;

    await webdavClient.putFileContents(savePath, buffer, {
      overwrite: true,
    });

    ctx.logger.info(
      `${filename} 已保存至 ${ctx.config.webdavUrl}/${ctx.config.rootFolder}/${savePath}`
    );
  }

  async function saveMface(mface: MfaceElement, folder?: string) {
    if (folder && !(await webdavClient.exists(`/${folder}`))) {
      await webdavClient.createDirectory(`/${folder}`);
    }

    const extension = mface.url.split(".").pop();
    const filename = `${mface.emojiPackageId}-${mface.summary}.${extension}`;
    const savePath = `${folder ? folder + "/" : ""}${filename}`;

    let buffer = await ctx.http.get(mface.url);
    await webdavClient.putFileContents(savePath, buffer, {
      overwrite: true,
    });

    ctx.logger.info(
      `${filename} 已保存至 ${ctx.config.webdavUrl}/${ctx.config.rootFolder}/${savePath}`
    );
  }

  ctx
    .user(...ctx.config.allowUsers)
    .command("save-sticker <folder:text>", "获取表情包", {
      // @ts-ignore-next-line
      hidden: true,
      captureQuote: false,
    })
    .alias("盗图", "保存图片")
    .action(async ({ session }, folder) => {
      const quote = session.quote;
      ctx.logger.info(quote, "quote");
      if (!quote) return;

      const images: Array<ImageElement> = [];
      const mfaces: Array<MfaceElement> = [];

      quote.elements.forEach((el) => {
        if (el.type === "img") {
          images.push(el.attrs as ImageElement);
        }
        if (el.type === "mface") {
          mfaces.push(el.attrs as MfaceElement);
        }
      });

      if (images.length === 0 && mfaces.length === 0) {
        session.send("引用的消息里没有图片吧");
        return;
      }

      ctx.logger.info({ images, mfaces, folder });
      const promises = [
        ...images.map((image) => saveImage(image, folder)),
        ...mfaces.map((mface) => saveMface(mface, folder)),
      ];

      Promise.allSettled(promises).then((results) => {
        const rejected = results.filter((r) => r.status === "rejected");
        const fulfilled = results.filter((r) => r.status === "fulfilled");

        if (fulfilled.length === 0) {
          session.send("没有拿到图片，好像出了点问题...");
        } else if (fulfilled.length > 0 && rejected.length > 0) {
          session.send("部分图片没有拿到...");
        } else {
          session.send(Random.pick(ctx.config.successMessage));
        }
        if (rejected.length > 0) {
          ctx.logger.error(rejected.map((r) => r.reason));
        }
      });
    });
}

抽签

我已经在西安暂住下来，并且开始逐渐了解这座城市

我做了一件很不得了的事情，至少我自己觉得很厉害！

9.24 和 9.25 这两天的时间，骑上我的本田 cc110，从洛阳到达了西安

完成了人生第一次摩托车旅行

每年最完美的季节

小熊说，Cub 可以带我去任何地方，我还想去更远的地方

芝麻凛的爷爷说，我刚拿到驾照可能会不知道，季节交替的时候正式摩托旅行的好时机

摩托旅行是视野最开阔的旅行方式，有速度，有风，眼前所有的东西全是景色

出发前的心情和准备

喜欢的事情

早在今年一月份的时候，看了动画片《本田小狼与我》

再之后，看了《摇曳露营 3》

这两个动画片让我知道摩托车可以是生活的一部分，是一种人生态度，是可以陪伴到老的东西

是接近我的理想，值得我去向往和追求的事物

七月份拿到驾照和车之后，我就摩拳擦掌想要试一次摩托旅行。于是从家里骑到了陆浑水库

在陆浑环湖骑行了一圈。我确信我做了正确的决定，我喜欢的就是这样的东西

我觉得这是给自己放暑假期间做的最有意义的事情了

悠闲，还有些害怕

暑假过的很快，弟弟的暑假在九月份结束了，我意识到我差不多也该重新组织自己的生活了

我想把骑行继续下去，所以目光看向了洛阳旁边的城市西安，我觉得西安应该是一个很舒服的地方，吃得惯住得惯，骑行环境好，机车天堂

了解长途骑行的知识，护具的选购，防御性驾驶等等

买了护膝护肘护腰，一个很满意的后座包…

不害怕是不可能的，我知道国道路况没那么好，国道上非常多的挂车，可能会遇到横风，甚至落石

我也知道，如果出事故，一切都会结束。是很可怕的事情…

除此之外，我去西安是找工作的，如果没找到的话会怎样，重新安排之后的事情…

做出决定的时候，是稍微有些焦虑的，甚至犹豫这趟危险的骑行是不是不对的

后来朋友一句话把我点醒了

在后座包上扣了芙莉莲的吧唧，伊蕾娜和小熊的挂饰，还有友人送的护身符

带着些许畏惧，还有许许多多期待，开始了第一次摩旅

出发，我一直都在路上

9.24 上午，去邻村喝了碗豆腐脑，吃了两个水煎包回家。把沉重的后座包放在车上

准备出发的时候遇到老爸，原来是出门给我买了点吃的，几个苹果，一袋玉米肠，还有点心。叮嘱我在路上多休息休息

由于行李空间有限，我只带了玉米肠和一个苹果还有说不出的感谢

穿上护具，目标 大雁塔，出发

第一天：洛阳 - 潼关

出发不一会儿就从瀍河上了洛阳段的 310 国道

一个转弯进入国道，视野开阔起来，洛阳段的国道修得真好，双向六车道，路边是山山水水和村庄

也许是因为我的详细计划，选了一个晴天的工作日，国道并没有我想象的那么危险，虽然大车也不少，但是路很宽

我骑在最右车道最右侧 30 公分的距离，如果左后视镜里有大车出现，我就乖巧地借用非机动车道，然后减速让大车先走

遵循这样的让车规则，渐渐在国道上稳定下来，不一会儿就到了三门峡

中午从义马下了国道，去吃了午饭，在饭店里休息了一个小时，继续出发！

下午也是一路骑行，在每个服务区都做了休息

一下午在服务区一共遇到了五个摩友，他们有来自山西的，来自陕西的，甚至还有江苏的大哥

在服务区简单聊天十分愉快，大家都会相互夸赞，聊一聊车，聊一聊沿路的景点

很少和陌生人聊的这么愉快过

休息之后各自分别，打一个再见的招呼，继续旅行，有几个大哥还会在下个服务区碰面

实际上，我骑车的速度要比导航计算的速度更慢

六点的时候太阳落山，骑车是最不舒服的，虽然有遮光镜，但是太阳光依然会直射前方…

但是有些不服输吧，心里想着第一天要进入陕西界

终于到了潼关，在此落脚，还吃了个肉夹馍~

如此，第一天的旅行结束了

第二天：潼关 - 西安

前一天在酒店提前查了一下陕西段国道的路况（因为在渭南市下国道的时候，那段路实在有些糟糕）

改变了路线，决定不再走 310 国道，取而代之的是堤顶路

骑过之后才知道，堤顶路是沿着渭河修建的一条穿过渭南-西安-宝鸡的道路

这条路简直是为了旅游者而修建的，限高 2.2m，限速 60，意味着没有大车，希望旅行者慢慢走

这条路两边是田地，村庄，渭河。红绿顶非常少，甚至还有农民在路上晒玉米（毕竟是这个季节嘛

好在车非常少，景色优美，骑行心情悠然自得，太享受了

这张照片是从国道走入一条无名道路上，这条道路连接着国道和堤顶路，走上这条无名路我就知道自己选对路了！

如此惬意，美好，自由

沿着这条路继续走下去，穿过了田野，穿过了华阴，见到渭河

这一路没有什么饭店，但是休息也没有国道上那么嘈杂，想停就停，停下也很安静

摘掉头盔，大口呼吸空气，吃点火腿肠，咬一口大苹果

休息的一刻，我也是自然的一部分

慢慢悠悠地，西安人民欢迎您

在西安界内，也是先沿着渭河堤走，渭河就在旁边

到西安之后明显发现摩托车变多了，好多酷炫的摩托佬

大概四点半的时候到达大雁塔，大雁塔红绿灯前草草拍了个照片，旅程算是结束了

我做到了！！

到达后的感想

第一次摩旅毕业了！

出发前是害怕和不安

出发后是紧张，稳稳骑行，珍惜自己的生命，感慨国道上开阔的视野

对骑车技术有把握之后，开始欣赏沿路的美景，享受旅行

到达目的地后，先前的不安和紧张都不再有了，取而代之的是豁然开朗！

还有对自己的肯定：我做到了！！

最初考虑，我会在西安住上一个月去找工作

但是当我到达的时候，已经觉得骑到西安这件事本身的价值已经超越了找工作，担心找不到工作的忧愁也不存在了

毕竟，西安不是我的终点，只是其中一站而已

在民宿住下之后去泡了个澡，把疲惫溶解在温泉里…

真让人脸扁~~

旅途的风景都在路上，生活是体验。我一直都在路上，我一直都在体验

出发和到达

8 月 23 号从洛阳坐高铁到长沙游玩，住在长沙县，星沙地铁站附近。朋友家楼上的公寓式酒店

去长沙之前，朋友还让我带了几个烧饼（笑

第一次伴手礼给人带烧饼的

到达长沙之后，收到了友人出差兰州带的博物馆文创

撸猫

到达长沙的第一件事情就是去朋友家撸猫

早在两年前，朋友在秦皇岛的时候我去住过，家里的两只猫猫太可爱了

喂猫条的是我，被喂猫条的叫黑米，正在被朋友 rua 的猫猫叫正正

猫猫的记忆是短暂的，他们俩都不认识我了（哭

小时候我还抱过你呢！

恰饭

晚上在楼下吃了一家名叫壹盏灯的长沙菜

哇 好辣好辣 每个菜都有辣椒

但是好香，辣椒和肉就好像西红柿和鸡蛋一般相配

游玩长沙

松雅湖

到达第一天晚上，吃过饭之后，去了松雅湖

在松雅湖租了一辆快乐的三人自行车

松雅湖周围是很完善的骑行道，有不少单车佬在这里飙车，道路两边也有足够多的便利店和厕所

很明显是有市政管理支持的景区

除了骑行，还有一个人工沙滩（难道是海边错觉？

沙滩不大，但是好多人在这里玩，城市松弛感的体现

这趟骑行大概花了两个多小时，好累，但是好爽，运动的疲惫在愉快的情绪里是可以转换成轻盈感的

城区漫步

第二天主要是逛街，这天走了两万三千步…

可能是因为在天津的运动量增加了体力上限，感觉好像没那么累

这一天的路线是：开福寺 - 黄兴路步行街 - 文和友 - 杜甫江阁

进入文和友很震撼，复古做旧的年代风味很有趣。黄兴路步行街展现了长沙现代化的一面。

橘子洲

第三天睡了个大懒觉，下午去橘子洲坐小火车

年轻时代的毛泽东雕像，眼里有光，有未来，深邃而威严

岳麓山的日出

第四天的一大早，三点起床打车去岳麓山看日出。

和天津那次的海边不同，这天看到了日出

但是太阳被该死的国金大厦挡住了 QAQ

可恶啊！！！

日出真好，日出的时候没有声音

沿着岳麓山的下山道，逐渐走到了湖南大学

湖南大学好大好大… 上双一流大学是什么感觉捏…

长沙香香

要说在长沙印象最好的东西，还是各路美食

常德津市牛肉粉、臭豆腐、东瓜山香肠、紫苏桃子、黄油粑粑、热卤、茶颜悦色

在长沙没有喝茶颜的奶茶，只喝了果茶和鸡尾酒，鸡尾酒非常好喝，是忘不了的味道

长沙的臭豆腐和外面的真的不一样，香，脆，辣，呛！

在长沙不紧不慢过的十分惬意…

好羡慕友人四处移动的自由生活，把生活本身变成旅游的一部分

上初中的弟弟也在放暑假，初中的弟弟还没出过远门，也想走出洛阳看看其他城市

于是，趁着这次休息，仔细计划了一番。和弟弟一起 出发！

行程

试着用多维表记录了一下行程，非常方便呢（安利一下 Flow us 这个软件）

我的行程都在下面的图片里啦，也可以作为天津旅游攻略的参考

游玩印象

所有的照片都在这里

到达天津

高铁下午到达，已经饿得不行了… 直接打车去了西北角美食街

这里稍微有点失望，就是很普通的县城小吃街（虽然绝对不是小县城

在这里吃了最顶饿的煎饼果子，还买了炸糕

煎饼果子是纯咸味的，比起山东的会更干一些，还挺好吃的。炸糕外脆里嫩，但是吃了几口就腻了（也可能是我吃饱了）

吃饱之后去和在天津出差的朋友碰面一起溜街子聊天

逛了意风区和古文化街，虽说是意风区，但是风味也不是那么浓…

在天津逛街是很惬意的，因为周围建筑各不相同，新鲜感！

晚上去了海河公园，绕着某两个桥之间走了走，看到一路上有弹吉他的市民和游泳的，海河是可以游泳的！

看得出天津真的有呵护这条母亲河

大光明桥:

五大道，博物馆，天津之眼

五大道是万国建筑群，名人故居，大多数故居都不对外开放，但是走在这样的街道里体验民国风情也很有趣

五大道的中心是视野开阔的民园广场，广场附近有好多小吃

来一碗津门老味刨冰！是夏天的清爽味道！

还有拉小提琴的老爷爷（拉的相当好）

之后去了天津博物馆，博物馆的一层和二层都挺一般的，没有什么亮点

但是从三层就不同了，来了天津，就一定绕不开近代历史。三楼就是这样展览馆。

近代历史展馆中有不少历史细节，比如战争的数据统计，交战双方的兵器，老照片等等，相当震撼

比如下面的兵器对比

↑ 这怎么可能打得赢 ↑

这让我想起了玩文明 6 的时候，游戏玩到后期和落后国家出现文明代差，直升机打弓箭手，坦克推中世纪城墙…..

对于晚清而言，确实是这样的体验吧 orz

清代的封闭统治毁了中国…

但是不能去责怪历史，因为历史不会变

博物馆四楼是一个临时展厅，内容是波罗的海琥珀展

有封印了远古虫族的橙黄琥珀化石，还有与金银加工的饰品。大开眼界

↑ 好像看到了艾尔登法环里的屎壳郎，打死可以获得失色锻造石吗 ↑

下午和搞定出差工作的朋友碰面，一起去袁世凯家做客（付费做客

第一张图片是从他家阳台上拍的海河，风景真好（这老东西真会挑地方住）

想去袁世凯家看看是因为这个视频

参观故居之后可以明显地感受到一些特点。

• 拥抱西方先进文化的同时又保守封建思维，家里的佛像和风水讲究。电视机和非常精密的钟表湿度计
• 想当皇帝，他是真的相做皇帝 hhhhh，一楼还有个龙椅呢（
• 兴趣广泛，麻将象棋牌九老照相机
• 胆小多疑，有很多逃生密道，在任何一层楼都可以随时出逃

晚上去了天津之眼，那个坐落在桥面上，一百多米高的巨大摩天轮

我只坐过上海动物园的小摩天轮，所以对这个特别向往。早早就订了票

摩天轮门票是 100/人，一圈大概 2 多分钟。白天和晚上去各有各的美景

要说有什么美中不足，就是摩天轮舱室的玻璃上有滤光膜，可能是担心白天的太阳炫光。但是这个滤光膜很影响拍照的质量

（好在手机 AI 相机有颜色校正）

国家海洋博物馆

第三天去了海洋博物馆，建在海边的博物馆

由于没有预约到门票，只能买馆内活动票送入馆门票… 这也算是变相门票收费了吧，不过很值得

展馆非常大，足够逛一整天的了，是个溜初中弟弟的好地方（

午饭是在馆内解决的，抱着食堂味道肯定一般般的心态去了深海中餐厅，结果大受震撼

这也 太好吃了叭！！

吃饭花了大概 160，味道绝赞，如果要去这里玩一定不要错过！

逛馆子还挺累的，下午稍微休息了一会儿，打车出发去东堤公园看海

晴天看海，海岸线有栏杆围着，不让下水，但是海岸线非常美

之后因为走累了就回酒店休息…

晚上的时候在塘沽找饭店，找到了一家叫红旗饭庄的店。又是一番味觉盛宴

让我来一一介绍！

• 第一个菜是茄夹，入口是口水茄子的酸甜咸口，外面的淀粉壳炸得很脆，里面的茄子是软糯的，但是这还没完，茄夹里有一颗不小的虾仁，吃到最后又有肉肉的感觉和鲜味。过口入肚之后会有一丝丝辣感，这才发现这道菜底部是有辣椒油，香辣脆口，味觉口感体验都极其丰富
• 第二个菜店里叫麻线。其实是烙饼、香葱和熟虾酱。这个菜弟弟吃不惯，我是因为好奇山东的虾酱风味（虽然是津菜）才点的。香葱，烙饼，虾酱，不论哪个单吃都非常难以下咽。但是加起来就是绝配，香葱掩盖了一小部分的虾酱的臭味，突出了鲜味，烙饼赋予了形状和口感，赞叹食材融合的智慧
• 最后一个是店里老板推荐的八珍豆腐，刚端上来的时候没看见豆腐，还以为上错菜了。直到夹了两筷子鱿鱼和黄瓜，才发现豆腐铺在最下面。于是用勺子挖了一勺豆腐和蛤蜊肉，嗯，绝了！

这个饭馆三道菜给了我巨大的惊喜，食材丰富，味觉和口感都有兼顾。可能这就是津菜的智慧吧！

后来把这个发给了天津友人，他也知道这家店。评价相当不错，如果要去天津，务必要尝一尝！

吃完饭之后回酒店的路上，看到有一家三福，以消食为目的去逛了逛，然后痛失一张粉红票票

前几个月看完葬送的芙莉莲之后，一直想买些小周边纪念一下，但是没有满意的，在三福发现了收藏卡，画面很棒。

除了芙芙，还看到了两个蝴蝶结，少女心突然颤动，一不小心就买了下来！谁可以拒绝可爱的蝴蝶结呢？

遗憾日出，返程

回酒店之后早早的就休息了，因为明天想去海边看日出

市政很贴心的有一条四点出发的日出东疆公交专线，我们第二天就是乘坐这个去的

值得一提的是，前一天晚上看天气预报是多云，抱着赌一把的心态出发了

结果我赌输了 QAQ

云层很厚，没有橘红色的日出，东疆亲海公园虽然能下水但是也不干净

于是回酒店继续睡，算是一个遗憾吧

睡醒之后去滨海文化中心打卡了滨海图书馆

书山和科技感的设计新颖独特

也许是因为成为网红打卡地了吧，游览人数比较多，并没有符合图书馆的那份安静

下午返回天津站附近，因为离得很近，所以准备看看世纪钟广场。结果世纪钟在修…

好像几年前世纪钟就坏掉停转了

然后去转了天津站附近的老街，很喜欢市中心老街的烟火气，如果下次来天津。我会想去哈尔滨路吃几次饭

可能正是因为这些老街里接地气的小吃，加上海河富有亲和力的市民文化，才会显得天津的节奏会舒缓一些吧

最后，到达天津站，卧铺一觉睡回家咯

回家的路上

在火车站的时候看到了 c 开头的火车。城际火车，忽然发觉，北京就和天津挨着

搜了一下从天津到故宫的行程，才一小时四十分钟! 比去滨海新区都快

如果不打算去天津海边的话，可以第三天去北京转转（？

要说这趟旅行中的遗憾，莫过于没有亲眼见证日出的那抹橘红了。其他的话，天津好像没有自然海岸线了，在出租车上的时候搜索了一下，十年前的填海造陆，把天然海岸线都埋在了地下，造陆之后利用率却很低

在天津四天三夜，游玩体验很棒。

海河，历史建筑，海边的博物馆，美食。都留下了难忘的记忆

在此之前，从事的项目都是小团队，一般只有一个前端开发（就是我）或者最多两个。代码想怎么写就怎么写。项目体量小所以混乱但高效

但是米哈游里的项目不同，有技术难点，开发团队人数多，上线质量要求高，沟通场景多，开发流程也比较严格。这种情况下，我欠缺的不再是解决问题的能力，而是对工作环境以及项目质量的适应性

团队协作

刚进入项目的时候只有五六个人，后来随着项目被上面重视，开始扩大规模，增加产能。人数最多的时候将近 20 人

随着人数增加出现过很多问题，比如合并代码丢失，大量代码冲突等问题。为了避免这些问题，做出了不少值得我学习的措施

迭代开发之前

正常的流程是: 需求评审 -> 设计评审 -> 前后端技术评审 -> 功能开发 -> 测试用例评审 -> 测试 -> 产品和 UI 验收 -> 发布

这样的流程在开发时基本上时清晰的，但是不可避免会出现开发测试期间需求变更的问题

在需求评审和技术评审的时候，程序员应该尽可能构建完整的开发思路，思考产品设计和现有功能的矛盾点，可行性如何，如果有问题，就告诉产品经理。这样做可以从需求合理性的角度避免开发期间的需求变更

（避免开发期间的需求变化就是减少加班）

编辑器统一

在项目中创建.vscode 文件夹，不要加入.gitignore，可以让团队每个人的编辑器设置保持一致。避免因为一些插件或者选项导致的提交冲突或者代码问题

1
2
3

./.vscode
├── extensions.json
└── settings.json

依赖统一

为了保证所有人的开发环境一致，不要把 lock 文件放入.gitignore

如果对代码一致性要求严格，可以在 package.json 里锁定版本

1
2
3
4
5
6
7
8
9
10
11

"dependencies": {
  "axios": "1.4.0",
  "dayjs": "1.10.7",
  "diff-match-patch": "1.0.5",
  "dompurify": "3.0.6",
  "downloadjs": "1.4.7",
  "echarts": "5.3.0",
  "event-source-polyfill": "1.0.31",
  "eventemitter3": "4.0.7",
  "exceljs": "4.3.0"
}

创建.npmrc 文件，统一 npm 源，以及项目里的一些 npm 设置

1

registry=https://XXX.com

建立 git 使用规范

分支管理

米哈游的本地化项目里有清晰的分支意义，分支与运行环境相关联：

master：同步预发布环境代码，添加 tag 时可以选择发布生产环境

pre: 预发布环境（生产环境，测试数据）

dev: 测试环境（测试环境，测试数据）

feat: 测试环境

需求确定后，从 dev 分支拉出自己的开发分支（feat）进行开发，开发完成后合入 dev 分支进入测试阶段

Merge Request

在此我只知道 pull request，拉去请求。团队内使用 gitlab，每当完成自己的 feat 分支开发时，会在 gitlab 上发起一个 merge request，代码 diff 通过 code review 之后才会合入 dev 分支

如果是需求开发，commit 的意义不需要保留，那么可以在 mr 的时候将多个 commit 压缩成一个

测试完成，进入预发环境的时候，会从 dev 提交一个 merge request 到 pre 分支，通过 diff 可以看到一次迭代修改的所有代码。根据 diff 进行 code review

git rebase

为保证提交历史的干净整洁，团队没有采用传统的 merge 合并代码，而是 rebase。

git rebase 相关的内容可以看这篇文章

既然使用了 rebase，有时候就需要对 commit 进行 drop 或者 squash 等一系列的操作。除了手动在命令行中使用git rebase -i 之外。更推荐使用 git 图形工具来做，比如fork

commitizen 和 git-cz

使用 commitizen 和 git-cz 来替代 git commit -m 可以约束项目参与者的提交信息

代码质量

除了团队协作中的约定，采用一些手段来确保项目成员所编写的代码质量也十分重要

TypeScript

如果项目比较大，业务逻辑复杂，引入 TS 是非常必要的。

编码效率方面，ts 会给出很好用的编辑器辅助

更重要的是代码的健壮性，给 JavaScript 添加类型约束之后，避免了很多 bug 的出现。而且在添加类型的过程中，也会修复许多的隐藏 bug

tsconfig 的文档

ESLint

ESLint 可以保证项目中的语言语法规范。

可以通过 .eslintrc 文件来约束语法使用，可以用.eslintignore 忽略某些文件的 ESLint 检查

项目里我们使用 ESLint + Prettier 格式化代码，ESLint 和 Prettier 可能会产生规则冲突，可以使用 eslint-config-prettier 这个工具辅助进行代码格式化

husky & lint-staged

除了写代码的时候进行格式化，在提交代码的时候也需要把暂存区的代码都进行一次 lint 和类型检查

husky用来在运行 git 命令的时候运行一些函数或者其他命令。比如 pre-commit 钩子

lint-staged用来过滤出暂存区的更改

所以 ts + eslint + husky + lint-staged 可以在 pre-commit 的时候 对暂存区的代码进行 lint。从而保证了每次 commit 的代码都是符合 ESLint 规则且没有 TS 问题的

流水线检查

除了提交的时候检查代码规范，还会在流水线运行的时候再做一次检查

流水线检查是为了避免代码合并后出现的问题

模块划分

清晰的模块划分可以提高代码的可维护性

我对模块的理解是：负责特定功能的独立的代码集合

模块之间可以有引用关系，但是引用关系必须是单向的。

项目中划分模块可以分为下面几种

• 通用模块：一些通用逻辑，比如登录，用户信息，全局状态。这些应该被独立为模块
• 工具模块：工具函数，网络请求的封装，日志等
• 业务模块：业务逻辑的分割

单元测试

单元测试是通过一些工具去验证程序的最小可测试部分是否按照期望结果运行

“单元”可能是一个函数，一个类，或者一个模块

单元测试的过程是：对单元指定运行环境，入参，期望结果。程序在指定环境中接收入参返回的结果是否与期望结果一致

关于什么是单元测试，单元测试的意义，以前的同事给过一篇知乎的答案来解释

在公司项目里，我们曾经使用 vitest 来做单元测试

1
2
3
4
5
6

"@vitest/coverage-istanbul": "^0.33.0",
"@vitest/coverage-v8": "^0.33.0",
"@vitest/ui": "^0.33.0",
"vitest": "^0.32.4",
"vitest-canvas-mock": "^0.3.2",
"msw": "^1.2.2",  // 用来mock请求

1
2
3
4

// sum.js
export function sum(a, b) {
  return a + b;
}

1
2
3
4
5
6
7

// sum.spec.js
import { expect, test } from "vitest";
import { sum } from "./sum.js";

test("adds 1 + 2 to equal 3", () => {
  expect(sum(1, 2)).toBe(3);
});

UI 自动化测试

相比单元测试，UI 自动化更偏向于视图的实际表现

UI 自动化就好像模拟人类在网页上的操作行为，测试用例基本都可以转化为 UI 自动化用例来执行。

UI 自动化的行为逻辑实际上是：登录（如果需要） -> 找到元素 -> 触发事件 -> 事件触发结果是否符合预期

可以使用 playwrite 库进行，以下是一个测试登录页面的例子

1
2
3
4
5

const AccountTest = {
  SUPER: ["account", "********"],
} as const;

export { AccountTest as Account };

封装测试工具

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

// e2e/utils.ts
import { test, type Page, type BrowserContext } from "@playwright/test";

export async function login(page: Page, account: readonly string[]) {
  await page.goto("#/login");
  await page.getByPlaceholder("请输入您的用户名").fill(account[0]);
  await page.getByPlaceholder("请输入您的密码").fill(account[1]);
  await page.click("#login > div.login-wrap > form > button");
  await page.waitForURL("**/*");
}

let seed = 0;
export function randomId() {
  return `${Date.now().toString(36)}0${seed++}`;
}

export function describe(
  title: string,
  cfg: { account: readonly string[] },
  cb: (parm: { page: Page }) => void
) {
  test.describe(title, () => {
    let ctx: BrowserContext;
    let page: Page;
    test.beforeAll(async ({ browser }) => {
      ctx = await browser.newContext();
      page = await ctx.newPage();
      await login(page, cfg.account);
      try {
        await page
          .getByRole("button", { name: "我知道了" })
          .click({ timeout: 100 });
      } catch (error) {}
    });

    test.afterAll(async () => {
      await page.close();
      await ctx.close();
    });

    cb({
      get page() {
        return page;
      },
    });
  });
}

自动化用例编写成本比较高，而且会因为迭代造成较大的变动

安全性检查

公司安全组会对项目进行安全性检查，寻找潜在的安全漏洞

主要包括 SQL 注入、XSS 攻击等

除此之外，npm 包也会要求使用公司的自建镜像。从而防止供应链攻击

运行监控

除了团队协作和代码规范，在代码发布到生产环境之后会采取一些措施来监控代码运行稳定性

埋点

通过埋点收集用户行为，埋点可以让产品经理分析用户的使用习惯。也可以给开发者复现生产环境错误提供线索

这是一个简单的埋点上报接口类型

1
2
3
4
5
6

interface Action {
  page: string;
  module: string;
  action: "click" | "view" | "scroll";
  extra: any;
}

错误监控

通过 Sentry 等工具对生产环境进行错误监控，可以收集到生产环境下程序运行出现的错误

许多报错往往看似不影响程序正常执行，但是在某些边界场景中，就有可能造成生产事故

收集生产环境的错误，及时修复。就如同在清理项目里的定时炸弹

记录一些对比之前不太一样的地方或者值得注意的地方

也会相对用的比较多的 Vue3，谈一些 React18 的理解

纯函数

react 特别强调函数要纯

不论是组件，还是对 state 的修改，一定要保持函数的纯粹性

https://zh-hans.react.dev/learn/keeping-components-pure

一个函数只做一件事情
输入相同，则输出相同
纯函数仅仅执行计算，因此调用它们两次不会改变任何东西

React 假设你编写的所有组件都是纯函数

不应该改变任何用于组件渲染的输入。这包括 props、state 和 context。通过 state 来更新界面，而不要改变预先存在的对象。

编写纯函数是编写 react 组件的前提条件

与函数的纯粹性相对的副作用，应该在 事件处理 或者 useEffect 中处理

严格模式

https://zh-hans.react.dev/learn/keeping-components-pure#detecting-impure-calculations-with-strict-mode

React 提供了 “严格模式”，在严格模式下开发时，它将会调用每个组件函数两次。通过重复调用组件函数，严格模式有助于找到违反这些规则的组件。

引入严格模式，可以用 <React.StrictMode> 包裹根组件。一些框架会默认这样做。

state 的快照理解和 Immer

下面这个例子，点击一次并不会使 number 的结果从 0 变成 3

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

import { useState } from "react";

export default function Counter() {
  const [number, setNumber] = useState(0);

  return (
    <>
      <h1>{number}</h1>
      <button
        onClick={() => {
          setNumber(number + 1);
          setNumber(number + 1);
          setNumber(number + 1);
        }}
      >
        +3
      </button>
    </>
  );
}

因为其等价于

1
2
3
4
5
6
7
8
9

<button
  onClick={() => {
    setNumber(0 + 1);
    setNumber(0 + 1);
    setNumber(0 + 1);
  }}
>
  +3
</button>

哪怕用 setTimeout 包裹其中一个 setTimeout 也不会影响结果：

1
2
3
4
5
6
7

<h1>{number}</h1>   // 0 -> 5
<button onClick={() => {
  setNumber(number + 5);
  setTimeout(() => {
    alert(number);  // 0
  }, 3000);
}}>+5</button>

一个 state 变量的值永远不会在一次渲染的内部发生变化， 即使其事件处理函数的代码是异步的。
React 会使 state 的值始终“固定”在一次渲染的各个事件处理函数内部。

渲染期间改变 state 的值

将 setNumber 的参数写成一个 纯函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

import { useState } from "react";

export default function Counter() {
  const [number, setNumber] = useState(0);

  return (
    <>
      <h1>{number}</h1>
      <button
        onClick={() => {
          setNumber((n) => n + 1);
          setNumber((n) => n + 1);
          setNumber((n) => n + 1);
        }}
      >
        +3
      </button>
    </>
  );
}

在一次渲染期间，会产生一个 state 的更新队列。例如上面的 state 更新队列可以表示为 [(n) => n + 1,(n) => n + 1,(n) => n + 1]

更新对象形式的 state

https://zh-hans.react.dev/learn/updating-objects-in-state#treat-state-as-read-only

如果 state 是一个对象，这个时候直接通过对象的引用关系去修改 state 是不正确的，这不会触发渲染

1
2
3

const [position, setPosition] = useState({ x: 0, y: 0 });

position.x = 1; // 当你这样做时，就制造了一个 mutation, state 应该是只读的

正确的写法应该是

1
2
3
4

setPosition({
  y: 0,
  x: 1,
});

如果对象复杂嵌套，这样书写也将变得非常繁琐，官方会推荐使用 Immer

使用 Immer

Immer 有点像 Vue3 中的 reactive，其原理都是使用 Proxy 记录对 state 的修改，并创建出新的对象

安装：npm install use-immer

1
2

const [position, updatePosition] = useImmer({ x: 0, y: 0 });
updatePosition((draft) => (draft.x = 1));

更新数组形式的 state

不论是数组还是对象，都要保持 state 的只读性

在使用setState去更新数组的时候，应该避免使用会修改原数组的方法，比如 push，unshift，pop，shift，splice，splice，arr[i] = ...，reverse，sort

如果使用 useImmer 声明 state，则可以使用所有的方法

状态管理的原则

这一部分算是响应式框架通用的一些原则，遵守这些原则，在代码组织上会显得更加合理

设计组件的思路

https://zh-hans.react.dev/learn/reacting-to-input-with-state#thinking-about-ui-declaratively

1. 分析组件所有可能存在的状态
2. 确定哪些因素可以改变这些状态，人为输入 or 计算机输入
3. 通过代码表示状态，useState 或者 ref
4. 连接状态和事件处理函数

构建 state 的原则

合并相关联的 state

如果一个动作往往要改动两个 state，两个 state 又相互独立，那么可以把两个 state 用一个对象包裹起来，每次都修改这个对象

避免矛盾的 state

用 一个 state 表示 typing sending sent 比 三个 state 表示 isTyping isSending isSent 要更好

用尽可能少的 state

相对来说，组件状态越少，组件维护起来的成本就越小。避免冗余的和重复的 state

没有必要把 props 镜像出一个 state

避免深度嵌套的 state

尽可能创建扁平化的 state

组件之间的 state

如果子组件之间有相互影响的 state，那么最好把它交给父组件管理

对于独特的状态，都应该有单一的数据源（state），这个 state 可以被传递，但是最好不要复制

组件内 state 的移除和保留

和 vue 一样，react 也有特殊的属性 key，更新 key 就会强制重置组件

统一管理状态和动作: 编写 reducer

https://zh-hans.react.dev/learn/extracting-state-logic-into-a-reducer#step-2-write-a-reducer-function

当组件的状态非常多的情况下，频繁地 setState 会让代码难以维护

如果能把更新状态的操作封装起来，用一个动作去表示，然后传入参数，就可以使引用更加清晰

reducer 是一个调度器，接收并执行不同的动作，返回新的结果

dispatch 用来发出动作，给出动作和计算新状态所需要的额外信息

要将状态设置逻辑从事件处理程序移到 reducer 函数中，你需要：

1. 声明当前状态（tasks）作为第一个参数；
2. 声明 action 对象作为第二个参数；
3. 从 reducer 返回 下一个 状态（React 会将旧的状态设置为这个最新的状态）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

function reducer(state, action) {
  switch(action) {
    case: 'action A' {
      const stateA = {
        ...state,
        // 一些因为 action A 而产生的变化
      }
      return stateA
    }
    case: 'action B'{
      const stateB = {
        ...state,
        // 一些因为 action B 而产生的变化
      }
      return stateB
    }
    default: {
      throw Error('未知 action: ' + action);
    }
  }
}

使用 useReducer 替代 useState

https://zh-hans.react.dev/reference/react/useReducer#dispatch

1
2
3
4
5
6
7
8
9

import { useReducer } from "react";
const [state, dispatch] = useReducer(reducer, initStates);

function handleEvent() {
  dispatch({
    type: "action",
    // new state
  });
}

与 setState 相同，reducer 也必须是纯函数，在修改对象或者数组的状态时，也需要替换整个数组或者对象

可以用 useImmerReducer 替换 useReducer 来简化 reducer 的写法

使用 context 深层传递参数

React 的 context 特性让我想到了 vue 的 provide 和 inject

两者都是解决组件参数传递层级过深的问题，只是写法不一样而已

创建 context

1
2
3
4

// 创建一个context, context.js
import { createContext } from "react";

export const Context = createContext(1);

父组件提供 context

1
2
3
4
5
6
7
8
9

import { Context } from "context.js";

export default function Section({ level, children }) {
  return (
    <section>
      <Context.Provider value={level}>{children}</Context.Provider>
    </section>
  );
}

子组件接收 context

1
2
3
4
5
6
7

import { useContext } from "react";
import { Context } from "context.js";

export default function Child() {
  const level = useContext(Context);
  return (...)
}

结合 useReducer 和 context，创建局部 store

https://zh-hans.react.dev/learn/scaling-up-with-reducer-and-context#combining-a-reducer-with-context

useReducer 可以将对数据的修改整理成 action ，通过 dispatch 一个动作更新状态

createContext 提供了一个局部共享的状态

将 useReducer 所提供的 state 和 dispatch函数 通过 context 传递给子组件，那么子组件就可以通过 action 修改父组件提供的状态了

这样做的好处是

1. 将 reducer 封装组件，子组件不需要关心父组件动作的对状态的具体修改，只需要派发动作就可以修改父组件的状态
2. 把 context 和 reducer 放在一起统一管理，使得负责构建 UI 的文件更加纯粹，视图和逻辑相分离

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

// AppContext.jsx ---------------------------
import { useReducer, createContext } from "react";

const AppContext = createContext();
// reducer 并不需要暴露出去
function reducer() {
  // ...
}

export function AppContextProvider({ children }) {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <AppContext.Provider value={{ state, dispatch }}>
      {children}
    </AppContext.Provider>
  );
}

// 父组件, 提供 context ------------

import { AppContextProvider } from "AppContext.jsx";

export default function ({ children }) {
  return <AppContextProvider>{children}</AppContextProvider>;
}

// 子组件, 消费 context --------------

import { useContext } from "react";

export function useAppContext() {
  const context = useContext(AppContext);
  if (!context) {
    throw new Error("useAppContext must be used within an AppProvider");
  }
  return context; // { state, dispatch }
}

react 里的 useRef

在我理解中的 Vue 和 React 框架设计的区别是，Vue 是响应性数据驱动更新视图，而 React 是状态驱动更新视图。
Vue 中的响应性数据：ref() 和 reactive() 声明的数据承载了表示状态的功能的同时也承载了可变性数据计算的功能。
React 的状态和可变性数据是分开的两个概念，state 只能由纯函数修改，并且具有不可变性，用来更新视图。ref 可以被随意修改，用来做与视图无关的计算
所以 React 中的 ref 并不会像 Vue 中的那样触发视图更新，只能用来承载组件内的数据计算或者 dom 操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 点击按钮后，打印结果会变成 1 ，但是视图依然是0
export default function MyRefComponent() {
  const ref = useRef(0);
  function handleChange() {
    ref.current += 1;
    console.log(ref.current);
  }
  return (
    <div>
      <p>{ref.current}</p>
      <button onClick={handleChange}>+1</button>
    </div>
  );
}

useRef 的 dom 操作

在这方面，react 和 vue 的差别不大

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import { useRef } from "react";

export default function Form() {
  const inputRef = useRef(null);

  function handleClick() {
    inputRef.current.focus();
  }

  return (
    <>
      <input ref={inputRef} />
      <button onClick={handleClick}>聚焦输入框</button>
    </>
  );
}

使用 flushSync 更新 state

flushSync 可以确保其回调函数内的更新立即反映到 dom 上
它和 nextTick 解决的问题相似：视图的更新是异步的，某些情况下希望在操作数据之后立刻对新的 dom 进行操作
如果回调内有大量的 dom 更新，将会出现性能问题

官方给出的例子

处理渲染本身产生的副作用：Effect

组件的状态变更会引起渲染，渲染会引起一些副作用，有些时候需要处理渲染引起的副作用，这就会用到 useEffect

1
2
3
4
5
6
7
8
9
10
11
12
13

import { useEffect } from "react";

function MyComponent() {
  useEffect(
    () => {
      // ...
      return () => {}; // 组件在重新执行effect之前，以及组件被卸载的时候，会调用这个清理函数
    },
    [
      /* 指定依赖 */
    ]
  );
}

useEffect 的回调函数会在渲染的提交阶段（也就是屏幕更新渲染之后）执行，使用 useEffect 需要显式指定依赖

指定依赖的数组中可以省略 ref

开发环境中 Effect 的重复执行问题

重复执行 React 的调试行为，Effect 的双重执行有利于开发者检测自己的 Effect 是否有清理函数终止掉多余的副作用

https://zh-hans.react.dev/learn/synchronizing-with-effects#how-to-handle-the-effect-firing-twice-in-development

Effect 常见用法

数据获取

1
2
3
4
5
6
7
8
9
10
11
12
13

import { useEffect, useState } from "react";

function DataFetchingComponent() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetch("https://api.example.com/data")
      .then((response) => response.json())
      .then((data) => setData(data));
  }, []); // 空数组表示这个 effect 只在组件挂载时执行一次

  return <div>{data ? JSON.stringify(data) : "Loading..."}</div>;
}

订阅或监听事件

在组件挂载时注册事件监听器或订阅某些服务，并在组件卸载时取消订阅。这些操作包括 WebSocket 连接、Redux store 订阅、浏览器事件（如键盘或鼠标事件）等。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import { useEffect } from "react";

function EventListenerComponent() {
  useEffect(() => {
    const handleResize = () => {
      console.log("Window resized");
    };
    window.addEventListener("resize", handleResize);

    // 清理函数，组件卸载时移除事件监听器
    return () => {
      window.removeEventListener("resize", handleResize);
    };
  }, []); // 空数组，effect 只在挂载和卸载时执行

  return <div>Resize the window and check the console.</div>;
}

定时器或者间隔

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import { useEffect, useState } from "react";

function TimerComponent() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const interval = setInterval(() => {
      setCount((c) => c + 1);
    }, 1000);

    // 清理函数，组件卸载时清除定时器
    return () => clearInterval(interval);
  }, []); // 空数组，effect 只在挂载时执行一次

  return <div>Count: {count}</div>;
}

依赖变化

类似于 Vue 中的 watch

1
2
3
4
5
6
7
8
9

import { useEffect, useState } from "react";

function CounterComponent({ count }) {
  useEffect(() => {
    console.log("Count changed:", count);
  }, [count]); // 只有 count 改变时，effect 才会重新执行

  return <div>Count: {count}</div>;
}

手动操作 dom

利用了 useEffect 在组件挂载之后执行一次的特性

不需要 Effect 的常见场景

https://zh-hans.react.dev/learn/you-might-not-need-an-effect

Effect 的生命周期

在 React 中，React 希望开发者将 Effect 的生命周期与组件的生命周期区分开来看待

组件的生命周期：

挂载 -> 更新 -> 卸载

Effect 的生命周期：

启动（Effect 函数执行） -> 依赖项更新（Effect 函数执行） -> 停止（清理函数执行）

即使没有依赖项，Effect 也会按照这个生命周期执行（仅执行一次，因为没有依赖项，自然也没有更新）

使用自定义 hook 抽离公共逻辑

Vue3 中也有类似的例子，在组件 setup 的时候，执行一些方法（同样约定以 use 开头），为组件提供一些预先封装好的功能

这是 React 给出的一个自定义 hook，用来给组件提供一个封装好 online 和 offline 事件并给出 isOnline 返回值的例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

function useOnlineStatus() {
  const [isOnline, setIsOnline] = useState(true);
  useEffect(() => {
    function handleOnline() {
      setIsOnline(true);
    }
    function handleOffline() {
      setIsOnline(false);
    }
    window.addEventListener("online", handleOnline);
    window.addEventListener("offline", handleOffline);
    return () => {
      window.removeEventListener("online", handleOnline);
      window.removeEventListener("offline", handleOffline);
    };
  }, []);
  return isOnline;
}

hook 和组件

React 应用是由组件构成，而组件由内置或自定义 Hook 构成。

React 约定
React 组件名称必须以大写字母开头
Hook 的名称必须以use开头，hook 可以返回任意值

关于 hook 的命名原则，是否所有渲染期间的调用函数都应该以 use 开头

使用 hook 封装的公共方法，应该被视为 hook，并以use作以标识

hook 的内容

自定义 hook 虽然可以提供 state，但是其重点在于所封装的逻辑，同时必须保持每次调用 hook 的独立性

自定义 hook 必须是纯函数

自定义 Hook 共享的只是状态逻辑而不是状态本身。对 Hook 的每个调用完全独立于对同一个 Hook 的其他调用。

学习 react18 过程中的术语概念

state & 快照

纯函数 & effect

ref

prop & context

hook

reducer & dispatch & action

文章写于 8 月份，这一年还没过完呢，后续还会更新

摇曳吼姆

2024 年所有的照片都在这里

封面：《变成菜变成花》

天冷我不冷，逛街！

我说谎了，其实我超懒的，我好怕冷，我好懒….

是有一个朋友把我给拉出来了，一月一号元旦，我们去了徐汇的美罗城

目的地是橡子共和国，吉卜力的周边专买店，以及美罗城其他的一些二次元店铺（太有活力了！）

算是给魔女宅急便这个动画片补票，所以相当满足

之后春节，在武汉的朋友回家之前来上海旅游，我就请了假和他一起逛二次元圣地魔都（？）

我们在 B 站的会员购上发现了一个 LoveLive 同好会的售票，最初以为是小型漫展。感觉只是逛店也好无聊，所以两个人就一起参加了这个同好会

这是我头一次去 Live house 在此之前我只在孤独摇滚里见过 Live House

这个不能被称之为漫展，因为这就是同好会！

先从检票说起，门口的检票是很无所谓的，甚至… 后面直接把检票给撤了。检票的好处是可以拿电子票换取两张明信片

因为是 Live House 所以主要是演出，除了演出没有其他的

这是我参加过最最最有 ACG 氛围的演出了，台上的 coser 用心的表演，台下的每个观众都跟着唱

刚进去的一瞬间我是震惊的，我是不是来错地方了… 哇！我的浓度远远不够

后面，我和朋友推测这是一个社团搞的活动，台下的大都是熟人，他们好像都认识？

总之，这是我去过最棒的一次 ACG 演出，没有任何一次漫展或者剧场比得上这次！

自驾舟山，学习开车

清明节假期的时候，我和两位关系很好的同事一起，租车去舟山自驾游玩。其目的一是玩，二是学习开车。

我高中毕业的时候就拿到驾照了，但是家里只有手动挡的车，我一开车老爸就骂我。索性不开了，反正我在外面也是打车比较多。目前没有开车的场景

有计划回家自驾游之后，开车就变成了比较重要的技能，于是下决心自己在上海学车！

旁边有老司机同事坐着，也不会像老爸一样怼我。车撞坏了也有全险，没有心理包袱很快就上手了：在舟山三天是我开的，高速上也开了一段。开车还是好玩的~ 稍微有些累

在舟山前两天玩的蛮开心！去了海滩，第一天吃的鱼很棒，之后去普陀岛逛的有些累。第三天从绍兴回上海

从结交到朋友这方面出发，我还是非常感谢米哈游的

在舟山岛留下了不错的回忆

跑路跑路

在去年的文章里提到过，现在的工作因为一些没意义的东西变得令人失望。

到今年三月份的时候，身边的同事都要走光了，原来十几个人的前端团队，现在只剩下五六个了

三月份我也接到了裁员的通知，意料之中，或者有点期待吧，因为早先熟悉的同事都不在了，大家上班也没有了最初的冲劲，每天打交道的人都满口黑话，不切实际，需求还没进入开发就先推卸未来的事故责任，说几句就令人厌烦。

二月份的时候就在想，如果离职了，应该好好休息几个月。因为现在工作不好找，既然不好找就更不应该在裁员潮和人竞争。家里也有不少事情，家里在盖房子，而且这几年都没回家，没有关注过家人的生活状态。回家之后也想给自己充充电，学点新技能，寻找一些新的爱好

和长沙工作的朋友，活力满满的天津友人，以及几个无所不能的网友讨论了上班和休息的事情，也得到了支持

四月底的时候离职了，把行李打包回家，我在上海的行李好多（我真的是来过日子的，不只是打工），邮寄花了一千还多。

走之前逛了好多馆子，一直想去但是没去成的天文馆水族馆自然博物馆。上海的展馆还是非常棒的

从杭州回家

行李寄回家之后，先去了杭州，游玩了西湖和良渚。

杭州的风景真棒啊！

吃了传说中无敌难吃的杭帮菜，西湖醋鱼

但是不够难吃，有点失望，后来问了店家，店家说稍微有些改进，把做醋鱼的西湖草鱼换成了鲈鱼（我就说嘛，吃起来没有土腥味也没有刺）

群友描述醋鱼的味道是这样的：浓郁的土腥伴随着酸涩不和谐的浓醋在嘴里爆开，漱口都难以清除的味道

嗯… 出于以上好奇去吃的… 所以稍微有点落差（不够难吃）

回到洛阳生活

虽然在外很长时间，但是各种生活习惯还是源自于洛阳的，比如自己做晚饭的话喜欢弄汤菜馍。

回洛阳之后才知道洛阳的美食是什么，油泼面，烧烤（每个地方的烧烤都不一样），糖葫芦，米皮凉皮擀面皮馄饨细米线，牛肉汤羊肉汤驴肉汤。卤肉和烧饼，烧鸡….

回家之后想做的事情

• 拿到本科毕业证和学士学位证
• 考取摩托车驾照，买摩托车
• 装饰一下自己的屋子，搞出一张理想的桌面
• 更换证件，身份证，驾照
• 开车自驾游
• 玩好多我想玩的游戏
• 关注一下家里盖房子的事情
• 整理网站，更换域名和服务器
• 学习一下服务端渲染框架
• 思考未来去哪里生活

事情算是不少的，不过时间很充裕

基本上是都完成了

本田小狼与我

因为今年看了一个动画片，本田小狼与我

印象里，摩托车是很猛汉有些危险的东西，但是以这个动画片为契机去深入了解之后，我也懂得了摩托车的魅力

作为交通工具，有他独特的浪漫，就像小狼说的，Cub 可以带我去任何地方，但是 Cub 也有做不到的事情…

本田小狼有独特的青春的味道，不同于挥洒汗水映出彩虹的热血，而是温和平静的自我满足和愉悦，发动机的震动和开阔的视野在心里开拓出了一片新世界

最好的风景在路上

六月底，拿到驾照之后，骑着摩托车去了一次洛阳陆浑，绕湖骑行的感觉真好

可爱的安达达和岛村村

但是近两年 B 站总是掐我的直播，因为版权问题或者不够和谐的问题… 直播间甚至被封过好几次

我还是挺珍惜自己的 6 级号的，但是也确实想以这种最直接的方式给朋友安利动画

从直播技术的角度看，B 站也好，斗鱼也好，本质都是本地推流，服务器处理流，客户端通过服务器链接接收流并播放

那么也许我可以自己搭建一个直播间

经过一番谷歌和 ChatGPT，最后找到了 livego 这个项目

livego 的优点很明显，就是简单，非常简单，熟悉一下文档之后，一行命令就可以跑起来

关于直播服务器

在印象里，直播一向都是很吃性能的一件事，他要捕捉画面，把画面转换成数据流，实时发送给服务端

但是以上这些都是客户端做的事情，实际上服务端对于性能的压力并不大，我测试过 1 核 2G 的服务器足够运行 livego 了

直播者 (OBS & 推流链接) -> 服务器 (livego) -> 用户 (播放链接 & 播放器)

推流比特率和分辨率

选择视频分辨率和相应的比特率。例如：

• 720p (HD): 大约 2.5 Mbps
• 1080p (Full HD): 大约 5 Mbps
• 4K (Ultra HD): 大约 15-25 Mbps

比特率越高，视频质量越好，但所需带宽也越高。

带宽

带宽涉及到本地推流带宽和服务器带宽

本地推流，本地上行带宽

我家网络很菜，上行带宽是 5Mbps，也就是说，我在使用 obs 推流的时候，码率不能超过 5Mbps，否则直播会出现断断续续的情况。保险起见，我在 obs 设置的码率是 4000Kbps，勉强可以让 1920*1080 分辨率不那么失真

直播服务器带宽

服务器需要接收到推流，并且把流分发给客户端。

所以，用户数量越大，所需要的带宽就越大，简要的计算方式如下

总带宽需求 = 单用户带宽需求 × 同时观看人数

以我个人的直播来讲，如果有 10 个人看，也就是需要 50Mbps 的带宽

服务器选择

总结下来，我的需求是：

直播观看用户不多，但是也需要不小的带宽

直播次数不多，所以直播流量不大，可能一个月只有几个 G

CPU 和内存要求不高

那么哪里有这样的服务器呢…. 高带宽，低流量，低性能，这种配置也太奇怪了

首先排除轻量应用服务器，限定死带宽的服务器一定不行。

经过一番努力，我终于找到了合适的，很便宜，并且满足需求的！

阿里云 99 块钱一年的服务器

虽然这个的固定带宽是 3M，但是可以通过升降配置把它改成按流量计费的

改成按流量计费之后，甚至还退了 49 块钱！

也就是，50 块钱拿下了一个 2 核 2G 大带宽的服务器

大概费用：每有一个人看，每小时大概 1 块钱流量费。我感觉很能接受

部署 livego 和使用

使用 docker 部署

首先安装 docker，使用官方脚本安装即可

1

curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun

安装好之后，从 docker 启动，并且给容器添加一个 name，方便容器挂掉之后重启

1

docker run --name livego-server -p 1935:1935 -p 7001:7001 -p 7002:7002 -p 8090:8090 -d gwuhaolin/livego

在安全组放行端口，上面端口的用处，可以看这张图片的备注列

使用 livego

创建房间，像文档里一样，访问地址：

http://ip 地址:8090/control/get?room=movie

页面会出现一个 json，里面包含了一个 key

推流

使用 rmtp 协议进行推流

obs 相关设置

播放

播放支持多种协议，也就是对应上面的端口

• RTMP: rtmp://ip:1935/live/movie
• FLV: http://ip:7001/live/movie.flv
• HLS: http://ip:7002/live/movie.m3u8

安卓可以使用KMSPlayer播放

windows 可以使用potplayer

macos 可以使用IINA

也可以自己使用 flv.js 构建一个网页播放器

以前这个博客是部署在阿里云的一台服务器上的，域名是 shirofune.cn

后来这台云服务器被我拿去直播服务器了

现在想把域名换成 homu.space ，同时换一台服务器，所以就重新部署一下

借着这个动机，顺便维护一下博客年久失修的依赖

新服务器的准备

添加虚拟内存

买了 99r 一年的服务器之后先 swap 一些虚拟内存

我用的是一个开箱即用的工具脚本

关于 swap 的一些介绍，还有具体的命令行操作可以看这个视频

更新 package

1
2

sudo -i
apt update -y # 升级 packages

安装 docker

caddy 是一个 nginx 的替代

我希望通过 docker 来运行 caddy

官方提供了一个一键安装的脚本，脚本包含了 docker-compose

但是需要注意的是，要加上 --mirror 参数，指定国内镜像

1

curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun

设置一下 docker 镜像源，因为官方的 dockerhub 被墙了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

vim /etc/docker/daemon.json

{
  "registry-mirrors": [
    "https://ustc-edu-cn.mirror.aliyuncs.com",
    "https://registry.docker-cn.com",
    "http://hub-mirror.c.163.com",
    "https://dockerhub.azk8s.cn",
    "https://ccr.ccs.tencentyun.com",
    "https://registry.cn-hangzhou.aliyuncs.com",
    "https://docker.mirrors.ustc.edu.cn",
    "https://docker.m.daocloud.io",
    "https://noohub.ru",
    "https://huecker.io",
    "https://dockerhub.timeweb.cloud"
  ]
}

systemctl daemon-reload
systemctl restart docker

docker info

博客存放路径和 git 空仓库

1
2
3

mkdir -p ~/site/hexo
mkdir -p ~/repo
git init --bare ~/repo/hexo-blog.git

编辑 git 钩子

1
2
3
4
5

vim ~/repo/hexo-blog.git/hooks/post-receive

#!/bin/bash

git --work-tree=/home/username/site/hexo --git-dir=/home/username/repo/hexo-blog.git checkout -f

运行 caddy

我使用了 docker-compose 来编排 caddy 的运行参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

version: "3"

services:
  caddy:
    container_name: caddy
    image: caddy:latest
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile # 同目录下写好 Caddyfile 配置文件
      - /home/ubuntu/site/hexo/:/srv # 把静态资源映射到docker容器内的/srv
      - caddy_data:/data # 存放caddy的ssl证书
      - caddy_config:/config
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
volumes:
  caddy_data:
    external: true
  caddy_config:

Caddyfile 是 caddy 的特殊配置文件，写法很简洁

Caddyfile:

1
2
3
4
5
6

blog.homu.space {
  root * /srv
  enable gzip
  file_server
  try_file {path}.html {path}/index.html # 省略后缀名
}

启动 caddy 镜像

1
2

docker volume create caddy_data
docker-compose up -d

免密推送

1
2

ssh-keygen -t rsa
cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

1
2
3

hexo d
# 或者
pnpm run deploy # package.json script

域名备案

前面说是想换域名到新的服务器

域名在阿里云买的，服务器在腾讯云…

在腾讯云选择备案服务。填写一堆表单之后提交就好了

备案周期很长，还会被驳回。建议拿到域名之后就备案

备案遇到的各种问题

由于先前我已经备案过一次了，shirofune.cn 这个域名。

所以工信部那边有我的备案主体和备案网站。

我再次进行个人备案，备案新的网站的时候，接到了云服务商的电话，说我上一个网站由于已经关停，变成了空壳网站，我也就变成了空壳主体，需要先注销掉空壳主体后执行初次备案。或者重新把之前的网站开起来

重新开起来网站这个好麻烦，备案的那个服务器已经被上一家云服务商回收了。所以只能注销

好在阿里云可以在控制台中注销备案

坏在我把网站注销备案之后，并没有注销掉主体（这个时候我才知道，不论是个人还是企业，主体和网站是两个东西）

注销主体就无敌麻烦了！注销主体需要提供纸质材料邮寄到线下，或者去线下办理。

众所周知工信部办事效率很低… 且不说邮寄东西花的时间，动不动就是 20 天，40 天的办事周期（真是可悲）

再稍微等等，如果重新备案这条路太难走的话，还是考虑选择香港的服务器，买一台香港的 VPS 去部署服务（一年会贵几百块钱）

整理博客

因为博客本身很长时间没有维护，所以花时间整理了一下相关代码

解决一些命令行报错

删除了一些用不到的依赖（package.json）

使用 pnpm

放弃全局 hexo-cli，使用项目内的命令来操作 hexo

更新 hexo 依赖版本，更新 butterfly 主题版本

删除（或隐藏）了一些文章

上海大雪

虽然不知道地球什么时候毁灭，但是上海确实下大雪了，虽然很短暂

(视频里大名鼎鼎的七宝万科，好像已经没了)

春节回家

在洛河边拍出了一张朦朦胧胧的照片，非常喜欢

春节假期，在洛阳去了偃师的虎头山和首阳山，普通的散步道，简单愉快

照片在这里

从洛阳回上海坐飞机，到达上海的时候是夜晚

有幸看到了非常漂亮的俯瞰夜景

露营的想法

三月份是最有活力的时候，工作稳定，生活轻松。加上天气慢慢温暖，有了倾向户外的想法

春天的时候，去公园里和朋友一起坐着晒太阳，打打羽毛球。很舒服呢

团建

在米哈游的团建，实际上就是出去吃饭。不论是正式员工还是 mi 岗员工，每个月都有 170 的团建报销额度。

所以团建单纯就是把这 170 给霍霍掉，总不能便宜了公司对吧

印象里项目组整体出去有两次，一次去吃了高丽菜，产品同事带领的。一次是项目管理带领的去玩（我没参加）

相比项目组整体，前端自己去的次数比较多（目的地海底捞居多）

不过捏… 据同事的不完全统计，每次一起下馆子，就会有个人被辞退或者离职

hhh…

用心推荐的上海动物园

四月份，已经暖和起来了，去了上海动物园。

十分感叹，这才是我梦想中的动物园啊…

这里是在动物园拍的照片

喜欢的生日礼物

今年过生日收到了一盏星空投影灯，在夜晚，我的天花板会变成一片星空

小浪底水库

六月端午，刚好是小浪底水库调水，和老爸开车就去了，场面相当壮观

更多照片在这里

BW & 南京东路的二次元街道

七月份参加了国内规模比较大的漫展，bilibili world

和高中时代带我一起玩 ACGN 的大姐姐一起去的，是为我打开新世界大门的大姐姐！

因为有前辈一起逛街聊天，所以非常愉快，这场漫展本身就是一个消费平台，并没有让人感动的氛围

更多照片在这里哦

第二天去逛了淮海中路那边孤独摇滚联动的索尼店，其实是因为耳机坏了，去取修好的耳机（WF1000xm4）

不得不说索尼的品控真的很一般

八月份的时候，有个朋友从亚美利加回国，准备在上海找个短期工作，并且体验一下魔都的二次元味道。

我们一起去了雾雨咖啡厅，一家东方主题的小咖啡店。店里铺满了店长的周边，是梦幻的小屋呢

之后一起去了百米香榭，看到了很多二次元遗老的周边。果然心动的东西还是要去中古店找啊

这里是逛街的照片

和表弟一起过十一假期

十月份的时候，毕业许久没找到工作的表弟决定来上海试试

但是从一开始我就没有抱有很大的希望

因为我觉得，找不到工作的原因并不是能力不够或者什么，而是不知道找什么，术业有专攻，没有专攻就不会有术和业

教给弟弟怎么找房子，然后找工作也给了一些建议，能做的事情也尽可能的帮了

之后，十一假期就一起去逛景区啦

函授学位证

十月底参加了学位证考试，请假去河南焦作的河南理工大学考试

这是我头一次来学校里面，学校还蛮大的，风景很不错

考试很简单，单考一门英语，难度还可以，程序员英语勉勉强强给糊弄过去了

十一月份的时候得到考试通过的结果，剩下的只有毕业论文就毕业啦

考完试，下午去爬云台山，云台山能玩两天的，不过和家人只逛了一下午，晚上就回家了

照片在这里

新的电子产品

十一月份花了好多钱 QAQ

先后买了 MacBook 和小米手机

Mac 主要用来做开发用，写笔记什么的很舒服（但是从事后看来，我还是太理想了，装上 windows 虚拟机打 galgame 也挺舒服的（（（

自己用贴纸装饰了手机，我喜欢小一点的屏幕，小米 14 是今年发布的手机中唯一一个个头比较小的（除了 iphone15）

工作心情

春节后，工作地点就被调换了。本来是在枫林园区的，那边很好，办公室人也不太多，相对自由。

工作虽然比较多，但是也能每天安排在下班前搞定。

在枫林的日子整体是比较轻松愉快的，和同事也建立了深厚的友谊

由于我们是给原神组（甲方）做平台的，甲方希望我们和他们坐在一起，这样对接更方便…

听起来是很合理，但是实际上却非常不正确。

实际上，甲方是提出需求的，而且我们项目组这边有专门负责对接需求并且将需求转化为项目排期和需求文档（PRD）的产品经理和项目管理，实际上甲方对接的目标是两位 PM 就对了（产品和项目管理）

原神组权力还是比较大的，说让我们过去，我们就得过去。

理想中的大厂程序员，埋头实现需求，和上下游同事做好沟通就可以了。这样才能把程序员的价值发挥到最大化，就我本身而言，我也期望这样。实现自己价值的同时还能学习，还不被公司里的冗杂事情所干涉。

过去之后就不一样了，甲方会直接找到我们开发，同时也会给产品和项管更大的压力。总而言之，先前建立的工作流被新插入的，不懂开发的其他组给破坏了

工作排期出现了严重问题，产品也趋向于不合理，开发也经常做起客服的工作

除此之外，测试那边填上了一个不解决问题不工作，每天玩企业微信，只会问责的领导。

从测试那边开始，卷起来了。因为不合理的流程和不干活的人，这份工作逐渐也变得困难

对大家直接的影响就是，纯粹的工作时间变少了，工作量增加且不合理，排期更紧张，同事关系变得糟糕，压力更大

这种崩坏是渐进的，从三月份开始，直到我今年（24）年离职。从我的视角来看，从三月份到 24 年三月份，先前努力工作的人要么被辞退，要么开始摆烂等着被辞退，实际不工作，喜欢搞流程，对上管理的那些人留了下来。

到 23 年年底，实际上已经有产品缩水的现象了，要么产品妥协，要么砍掉需求。因为实际问题是做不完，所有人每天加班也做不完。

也就是这个原因吧，我对米哈游失望了。

我是不怎么加班的，我痛恨体制性加班，为了给人做样子而加班。我会想尽办法去在上班的时间内完成我的工作

我相信我只要把精力投入工作，上班时间不摸鱼，下班时间自然也能走。

事实上我做到了，即使恪守不加班原则，我也完成了分配给我的需求，并且高质量完成（没出过什么线上问题）

所以，可能不太愉快，可能非常辛苦，但是我对自己在米哈游时期的表现是满意的

即使米哈游的工作氛围辜负了我的期望，我也没有认为自己选择来这里是错误的

我得到了我想要的东西

• 大公司的经验
• 喜欢的游戏公司的憧憬
• 技术进步，代码更规范
• 结交到新的朋友

失去的东西和得到的东西

一整年都在殷实的工作，解决过各种问题，也见过职场百态

失去最多的东西是活力，因为上班很累，回到家之后如果不是有游戏搭子粘着我打游戏，甚至连电脑都懒得开….

去年写日记的习惯，今年也没有了。虽然在工作里积累了很多经验，但是博客更新却变少了

看的动画片少了。缺少了努力追逐偶像，追逐角色的动力，现在只是去关注，出周边了买，出视频了看，只能得到一时的满足

虽然有经常出去玩，但是生活的乐趣确实减少了。

未来会以守护爱好作为前提去工作！

与此同时，得到的也很多嘛

首先就是钱钱，这一年确实赚到了钱钱，而且买了好多周边和手办，成就了学生时代的梦想（我的圆神手办！）

这一年在互联网上和朋友交流更多，试着和大家见面，收到了不少的礼物。非常开心，非常珍贵

各种信件，还有来自霓虹的留学生信件，同事去霓虹旅游带给我的伴手礼护身符，作为生日礼物的 cd…

这些都是猫咪的宝物！

这一年吃到了很多美食，国内的国外的各种不同风格的菜。味蕾环游世界

最后

今年难忘的游戏：塞尔达，星之卡比
今年的年度歌手依然是鹿乃

总结下来，这是平稳和积累的一年

实现水印的思路

从页面层次上来看，水印可以理解为覆盖在最高层的一层透明背景，虽然覆盖在最高层，但是不应该影响底层任何事件的触发

可以通过 canvas 绘制字符串的图片，然后转化为图片作为背景循环平铺到一个 div 里

这个 div 就是水印图

代码实现

绘制水印图片

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

function setWatermark(str: string): HTMLDivElement | null {
  const id = "1.1351.1561.215515";
  const lastEle = document.getElementById(id);

  if (lastEle !== null) {
    document.body.removeChild(lastEle);
  }

  const canvas = document.createElement("canvas");
  const body = document.querySelector("body");

  const clientWidth = body?.clientWidth ?? 0;
  const clientHeight = body?.clientHeight ?? 0;

  const ctx = canvas.getContext("2d");
  if (!ctx) return null;

  // 获取被测量字符串的宽度
  const strWidth = ctx.measureText(str).width;
  // 通过文字倾斜程度，算出canvas应有的宽高
  const canvasW = strWidth * Math.cos((30 / 180) * Math.PI) + 100;
  const canvasH = strWidth * Math.sin((30 / 180) * Math.PI) + 100;

  canvas.style.width = `${canvasW}px`;
  canvas.style.height = `${canvasH}px`;

  canvas.width = canvasW;
  canvas.height = canvasH;

  // 绘制文字
  ctx.rotate((-30 * Math.PI) / 180);
  ctx.font = "14px PingFang SC";
  ctx.fillStyle = "rgba(0, 0, 0, 0.05)";
  ctx.textAlign = "left";
  ctx.textBaseline = "bottom";
  ctx.fillText(str, 0, canvas.height);

  const ele = document.createElement("div");
  ele.id = id;
  ele.style.pointerEvents = "none";
  ele.style.top = "0px";
  ele.style.position = "fixed";
  ele.style.zIndex = "100000";
  // 覆盖body
  ele.style.width = `${clientWidth}px`;
  ele.style.height = `${clientHeight}px`;

  // canvas 转 data:url
  canvas.toBlob((blob) => {
    const newImg = document.createElement("img");
    const url = URL.createObjectURL(blob || new Blob());
    newImg.onload = function () {
      URL.revokeObjectURL(url);
    };
    ele.style.background = `url(${url}) left top repeat`;
  });
  document.body.appendChild(ele);
  return ele;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

class Watermark {
  // 设置水印
  static set(str: string) {
    let ele = setWatermark(str);

    setInterval(() => {
      if (
        !ele ||
        document.getElementById(ele.id) === null ||
        !ele.style.background
      ) {
        ele = setWatermark(str);
      }
    }, 500);

    window.onresize = () => {
      setWatermark(str);
    };
  }

  static outWatermark(id: string) {
    const div = document.getElementById(id);
    if (div !== null && div) div.style.display = "none";
  }
  // 隐藏水印
  static out() {
    const id = "1.1351.1561.215515";
    Watermark.outWatermark(id);
  }
}

设置水印

1

Watermark.set(`吼姆小行星`);

隐藏水印：

1

Watermark.out();

rebase，正如字面意思，重新选择基点

比如下面这个图，这张图片里有两个分支 feature 和 master

起初，两个分支均为 commit A 为基点，feature 分支延伸出了 D 和 E 两个 commit，master分支延伸出了B和C两个 commit

如果执行了在master分支执行

1
2

# at branch feature
git rebase master

则feature分支的基点会从A变成 master的最新 commit C。这就是 rebase

rebase 之后，不论是 feature 还是 master ，他们都在同一条提交线上

对比 rebase 和 merge

还用上面的例子

有这样的一个提交例子

现在试一下不同的操作对提交树产生的影响

如果使用 rebase

为保证相同的顺序 (ABCDE)，需要切换到 feature 分支，rebase master 分支

1
2

# at branch feature
git rebase master

如果使用 merge

1
2

# at branch master
git merge feature

使用 merge 依然是两条线，使用 rebase 则是一条线

使用 merge 还多出了一个 commit

使用 rebase 整理提交历史

除了用来合并代码，rebase 还可以用来整理提交历史

触发交互式 rebase：--interactive -i

继续上面的例子，选定 commit A 为基点，执行命令

1

git rebase -i `commit A`

执行命令后会进入一个编辑界面

pick（或 p）：保留该提交。
reword（或 r）：保留提交但修改提交消息。
edit（或 e）：暂停 rebase 并允许你修改该提交，比如修改内容、添加文件等。
squash（或 s）：将该提交与前一个提交合并。你可以修改合并后的提交信息。
fixup（或 f）：与 squash 类似，但丢弃当前提交的提交信息，直接合并到前一个提交。
exec（或 x）：在当前提交点执行一个 shell 命令。
drop（或 d）：删除该提交。

假设希望删除 commit E 这次提交，把 C 和 D 压缩成一个 commit，并且修改 commit 消息为 CD，可以这样做

保存之后，会提示修改 commit 消息

之后，提交历史会变成这个样子

cherry-pick

cherry-pick，摘樱桃。很形象地表示这个命令是要从提交树上删除掉一些 commit，和 git rebase -i 中的 drop 操作类似

这个命令经常配合 rebase 使用，比如某次提交的代码有问题，可以先备份一下，然后从主分支 cherry-pick 掉

cherry-pick 多个 commit 的时候，需要按照与原始顺序相反的顺序来删除

如果 commit1 依赖于 commit2，那么应该是

1

git cherry-pick <commit1> <commit2>

这样有利于减少冲突，避免依赖性问题

冲突解决

rebase 和 cherry-pick 也会产生冲突，并且解决步骤和 merge 不同

merge 是将一条分支上的所有代码汇入另一条分支，其操作的维度是分支，所以只会有一次冲突

而 rebase 不同，rebase 的操作维度是 commit，以上面 ABCDE 的 rebase 过程为例，D和E 在 rebase 到 C 上面的时候，如果 D 和 E 对比 BC 均有冲突，那么应该解决 D 和 E 造成的两次冲突，rebase 的分支有几个 commit 就可能最多产生多少次的冲突

如果一条分支不需要 commit 的每个细节，则可以利用 rebase -i 压缩(squash) 掉 commit

解决冲突的方式也和 merge 的重新提交不同，应该先把冲突的解决结果使用 add 命令提交到暂存区，然后使用 continue 解决下一个 rebase 的冲突。如此循环，直到没有冲突为准

1
2

git add .
git rebase --continue

rebase 的优点和缺点

rebase 的优点

• rebase 保持了提交历史的线性和简洁，方便管理
• 有效减少了合并提交，让每个 commit 都有意义

rebase 的缺点

• 操作不当会丢代码，如果没有分支备份，在解决冲突的时候，以及使用 drop 和 cherry-pick 的时候，会造成代码的丢失
• 解决冲突的过程比较复杂
• 依赖历史 commit 的线性结构
• 开发过程中断的情况，如果某个分支被搁置了很久，这个分支再去 rebase 最新代码的时候，可能会产生巨量的冲突需要解决

分支管理和使用经历

在米哈游的平台组工作时，前端团队用的就是 rebase 的管理方式。

维护协作分支 develop(ci 对应 test 环境)，pre 和 master 分支(ci 对应 pre 环境)，tag 为线上环境发布。

在进行需求开发的时候，每个人会从 develop 分支拉出自己的开发分支，在提测的时候，会将自己的开发分支 rebase 一下 develop，通过 git lab 提交 merge request 进入 develop 测试环境。

团队大约十几个人，同时开发多个模块，使用 merge 的话会让提交树变得非常复杂，难以从中间摘掉某个提交，或者快速定位和解决问题。rebase 是非常好的管理方式。

原文地址

原文是一篇讲得很明白的文章，本文基本上是照着写了一遍
不但学到了 VDOM 相关的一些东西，原生 JS 的方法也熟悉了一遍，收获颇丰

一文说清「VirtualDOM」的含义与实现

如何理解 VDom

前端常做的事情就是根据数据状态的更新，来更新页面视图。然而频繁的更新 DOM 会造成回流或者重绘，引发性能下降，页面卡顿
因此我们需要方法避免频繁更新 DOM 树
思路就是对比 DOM 差距，只更新需要更新的节点，而不是整棵树
实现这个算法的基础，需要遍历 DOM 树的结点，来进行比较更新
为了更快地处理，不使用 DOM 对象，而改用 JS 对象
他就像是 JS 与 DOM 之间的一层缓存

如何表示 VDom

借助 ES6 的 class，表示 VDom 的语义化更强。一个基础的 VDom 需要有标签名，标签属性以及子节点

1
2
3
4
5
6
7

class Element {
  constructor(tagName, props, children) {
    this.tagName = tagName;
    this.props = props;
    this.children = children;
  }
}

为了更方便调用（不用每次都 new），将其封装返回实例的函数

1
2
3

function el(tagName, props, children) {
  return new Element(tagName, props, children);
}

用上面的方法表达 DOM 结构：

1
2
3

<div class="test">
  <span>span1</span>
</div>

用 VDom 表示 ↓

1
2

const span = el("span", {}, ["span1"]);
const div = el("div", { class: "test" }, [span]);

之后再对比和更新两棵 vdom 树的时候，将会涉及到将 VDom 渲染成真正的 Dom 节点。因此给class Element 增加render方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

class Element {
  constructor(tagName, props, children) {
    this.tagName = tagName;
    this.props = props;
    this.children = children;
  }
  render() {
    const dom = document.createElement(this.tagName);
    // 设置标签属性值
    Reflect.ownKeys(this.props).forEach((name) =>
      dom.setAttribute(name, this.props[name])
    );
    // 递归更新子节点
    this.children.forEach((child) => {
      const childDom =
        child instanceof Element
          ? child.render()
          : document.createTextNode(child);
      dom.appendChild(childDom);
    });
    return dom;
  }
}

如何比较 dom 树，并且进行高效更新

前面已经说明了 VDom 的用法与含义， 多个 VDom 就会组成一棵虚拟的 VDom 树
剩下要做的就是：根据不同情况，来进行树上结点的增删改操作
这个过程分为diff和path

• diff: 递归对比两棵 dom 树对应位置的差异
• patch: 根据差异，进行节点的更新

现在有两种思路，一种是先 diff 一遍，记录所有差异，再统一进行 patch
另一种是 diff 同时进行 patch
相比较，第二种方法少了一次递归查询，以及不需要构造过多对象，下面采用第二种思路

变量的含义

将 diff 和 patch 的过程放入updateEl方法中

1
2
3
4
5
6
7
8

/**
 *
 * @param {HTMLElement} $parent
 * @param {Element} newNode
 * @param {Element} oldNode
 * @param {Number} index
 */
function updateEl($parent, newNode, oldNode, index = 0) {}

所有以$开头的变量，代表真实DOM
参数index表示oldNode再$parent 的所有子节点构成的数组的下标

1.新增节点

如果 oldNode 为 undefined，说明 newNode 是一个新增的 DOM 节点。将其直接追加到 DOM 中即可

1
2
3
4
5

function updateEl($parent, newNode, oldNode, index = 0) {
  if (!oldNode) {
    $parent.appendChild(newNode.render());
  }
}

2.删除节点

如果 newNode 为 undefined，说明新的 VDom 中，当前位置没有节点，因此需要将其从实际的 DOM 中删除
删除就调用$parent.removeChild(), 通过 index 参数，可以拿到被删除元素的引用

1
2
3
4
5
6
7

function updateEl($parent, newNode, oldNode, index = 0) {
  if (!oldNode) {
    $parent.appendChild(newNode.render());
  } else if (!newNode) {
    $parent.removeChild($parent.childNodes[index]);
  }
}

3.变化节点

对比 oldNode 和 newNode，有三种情况，均可视为改变

• 节点类型发生变化，文本变成 vdom，vdom 变成文本
• 新旧节点都是文本，内容改变
• 节点属性发生变化

首先，借助 Symbol 更好地语义化声明三种变化

1
2
3

const CHANGE_TYPE_TEXT = Symbol("text");
const CHANGE_TYPE_PROP = Symbol("props");
const CHANGE_TYPE_REPLACE = Symbol("replace");

针对节点属性发生改变，没有现成 API 供我们批量更新，所以封装replaceAttribute方法，将新的 vdom 属性值直接映射到 dom 结构上

1
2
3
4
5
6
7
8
9

function replaceAttribute($node, removedAttrs, newAttrs) {
  if (!$node) {
    return;
  }
  Reflect.ownKeys(removedAttrs).forEach((attr) => $node.removeAttribute(attr));
  Reflect.ownKeys(newAttrs).forEach((attr) =>
    $node.setAttribute(attr, newAttrs[attr])
  );
}

编写 checkChangeType 函数判断变化的类型，如果没有变化，则返回空

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

function checkChangeType(newNode, oldNode) {
  if (
    typeof newNode !== typeof oldNode ||
    newNode.tagName !== oldNode.tagName
  ) {
    return CHANGE_TYPE_REPLACE;
  }
  if (typeof newNode === "string") {
    if (newNode !== oldNode) {
      return CHANGE_TYPE_TEXT;
    }
    return;
  }
  const propsChanged = Reflect.ownKeys(newNode.props).reduce(
    (prev, name) => prev || oldNode.props[name] !== newNode.props[name],
    false
  );
  if (propsChanged) {
    return CHANGE_TYPE_PROP;
  }
  return;
}