「推广」 蓝易云商家 机器稳定建站服务器推荐

**蓝易云好不好? 蓝易云怎么样？香港服务器推荐。**

蓝易云，2020年成立的国人商家，是成都天上云网络科技有限公司旗下的云计算服务品牌，专注为个人开发者用户、中小型企业用户、大型企业用户提供云服务器、云虚拟主机、云数据库、云存储、域名、CDN、SSL证书、服务器租用托管等服务。

该商家主要定位建站服务器，特点是香港CN2网络，国内速度优秀，区域内支持VPC内网互联、快照、备份等功能。

蓝易云持有IDC、ISP、CDN许可证，为正规商家。

------

**机器特点：去程联通电信走CN2**

**回程 移动+联通+电信+教育网+广电+长城五网CN2-延迟超低！**

**CPU性能强劲，4核编译安装宝塔环境CPU只能占用到70%左右！**

**CPU单核GEEKBENCH跑分能到849分左右，lemonbench跑到能到942分左右。【优秀性能】**

------

**商家最新高防SCDN信息**

**蓝易云SCDN官网：[点击前往](https://www.tsycdn.com/)**

**无感防护 告别传统HTTP验证【可防HTTPS】 AI 智能全方位立体防护 专业算法**

**国内外加速 支持定制 【防住付款】 【现提供1元公益防护】接一切扛不住的攻击定制防护**

------

**以下是蓝易云SCDN控制台展示：**

[![SCDN控制台展示](https://www.8kiz.cn/usr/uploads/2022/11/1772025901.png)](https://www.8kiz.cn/usr/uploads/2022/11/1772025901.png)

[SCDN控制台展示](https://www.8kiz.cn/usr/uploads/2022/11/1772025901.png)



[![SCDN域名控制台展示](https://www.8kiz.cn/usr/uploads/2022/11/1580329632.png)](https://www.8kiz.cn/usr/uploads/2022/11/1580329632.png)

[SCDN域名控制台展示](https://www.8kiz.cn/usr/uploads/2022/11/1580329632.png)



------

**使用蓝易云SCDN网站的打开速度测试结果：**

[![网站打开测速结果](https://www.8kiz.cn/usr/uploads/2022/11/843195515.jpg)](https://www.8kiz.cn/usr/uploads/2022/11/843195515.jpg)

[网站打开测速结果](https://www.8kiz.cn/usr/uploads/2022/11/843195515.jpg)



------

**以下是蓝易云香港服务器质量介绍：**

| 香港九龙机房-双向CN2 vCPU：1核E5-2678 v3 @ 2.50GHz 内存：1G DDR4 硬盘：30G系统盘+20G数据盘 流量：500G流量/月（10Mbps端口） 价格：29元/月 购买：[点击直达](https://www.tsyvps.com/cart?action=configureproduct&pid=37) | 香港九龙机房-双向CN2 vCPU：1核E5-2678 v3 @ 2.50GHz 内存：2G DDR4 硬盘：30G系统盘+20G数据盘 带宽：500G流量/月（10Mbps端口） 价格：39元/月 购买：[点击直达](https://www.tsyvps.com/cart?action=configureproduct&pid=37) |
| :----------------------------------------------------------- | :----------------------------------------------------------- |
| **香港九龙机房-双向CN2 vCPU：2核E5-2678 v3 @ 2.50GHz 内存：4G DDR4  硬盘：30G系统盘+20G数据盘 带宽：500G流量/月（10Mbps端口） 价格：59元/月 购买：[点击直达](https://www.tsyvps.com/cart?action=configureproduct&pid=37)** | **香港九龙机房-双向CN2 vCPU：4核E5-2678 v3 @ 2.50GHz 内存：8G DDR4 硬盘：30G系统盘+20G数据盘 带宽：500G流量/月（10Mbps端口） 价格：109元/月 购买：[点击直达](https://www.tsyvps.com/cart?action=configureproduct&pid=37)** |

如需更多规格配置，可以根据需要自行选择，价格以商家官网为准。

**1H1G规格配置实际测试：**

**延迟** ：延迟方面可以看到基本都在40MS以内，直连线路延迟低。

[![全国ping延迟](https://www.8kiz.cn/usr/uploads/2022/10/4260263103.png)](https://www.8kiz.cn/usr/uploads/2022/10/4260263103.png)

[全国ping延迟](https://www.8kiz.cn/usr/uploads/2022/10/4260263103.png)



**性能 ：IO方面速度还不错，网络为上下对等10M CN2网络.**

[![IO速度](https://www.8kiz.cn/usr/uploads/2022/10/3010099974.png)](https://www.8kiz.cn/usr/uploads/2022/10/3010099974.png)

[IO速度](https://www.8kiz.cn/usr/uploads/2022/10/3010099974.png)



**CPU方面据商家描速进行了优化，GEEKBENCH跑分能到849分左右，lemonbench跑到能到942分左右。**

**根据商家描述香港云增强型性能 超越标准型30%，经实测达到商家描述！**

[![对比图](https://www.8kiz.cn/usr/uploads/2022/10/612993250.png)](https://www.8kiz.cn/usr/uploads/2022/10/612993250.png)

[对比图](https://www.8kiz.cn/usr/uploads/2022/10/612993250.png)



**线路 ：使用测试脚本进行回程路由测试，可以看到三网回程均为CN2网络【其他线路的忘记截屏了，大家可以自测】**

[![三网回程线路](https://www.8kiz.cn/usr/uploads/2022/10/3829922427.png)](https://www.8kiz.cn/usr/uploads/2022/10/3829922427.png)

[三网回程线路](https://www.8kiz.cn/usr/uploads/2022/10/3829922427.png)



**增强型网络得到进一步优化，相比标准型低10%左右延迟。**

**网络抖动**
**网络带宽充足，抖动较小，基本不丢包：**

[![网络稳定性](https://www.gd1214b.icu/post-images/1665469060269.png)](https://www.gd1214b.icu/post-images/1665469060269.png)

[网络稳定性](https://www.gd1214b.icu/post-images/1665469060269.png)



## 总结

**机器线路稳定，适合稳定建站，大带宽类型适合突发带宽访问用户，比较不错，CPU性能足够。**

**商家售后服务态度也不错，这点不错，值得推荐！**

关于B站“知名”鱼皮 UP 主，我对他的看法

首先，我要先说一件事： **文章带有严重主观色彩，这是没有办法的，但无论如何，这篇文章所描述的就是在 _我眼里的yupi_，如果你有合理的论据可以反对我对他的看法的，非常欢迎你拿着理智和论据来与我讨论**

**我会尽量保持客观地使用现存在的链接、真实的图片等来描述我的观点，遇到实在太主观的，你可以绕过去，我想说的是：不要只看主观部分，而不去看我用了具体链接、图片的部分**

此文永远备份于 GitHub：https://github.com/wibus-wee/weekly-issues/blob/main/joker_yupi.md

<details>
  <summary>吐槽一下 Profile</summary>
  <img width="387" alt="image" src="https://user-images.githubusercontent.com/62133302/200162966-595acf8c-ba45-4927-a7a1-9965d0bea89b.png">
</details>


~~这怎么还有语法错误的，一个句子俩谓语，这搁英文歌词也不能这么写吧~~


## 鱼皮，它不是一个人

```
wibus: 鱼皮？
wibus: 名曰为腾讯顶针
wibus: 知乎发「如何评价鱼皮Up主」发一个没一个
wibus: 他也是真的有时间，让我觉得现在就是互联网盛夏
```

在知乎逢是发「如何评价鱼皮Up主」等问题，在不久后你总是可以收到知乎的一份反馈：侵犯他人隐私，此话题已被关闭。不难想到这个就是被「鱼皮」关的

我们在这里先假设他是真的单干吧，但问题来了。如果他是单干的，那岂不是现在是真的互联网盛夏？在公司作为全栈开发者，有时间去做开源、做自媒体，这不是盛夏是什么？

除非他是公司里面专门做开源、自媒体的。你可能会问我，为什么要这么做？我这里简单说下我的观点吧：

> 让人都觉得编程很有前途，这样就会涌入一堆的小白，之后不管它中间怎么学的了 （极大可能也有暗合作） 最后就去互联网公司面试工作，暂且不说互联网公司之间有没有暗交，永远压榨人就已经是可以实现的了

当然，都是虚构的，都是我在胡说八道，如有雷同，那就是被我这种fw猜中了

yupi的产出速度太快了，他的每个项目都很全面，前后端都写好了，我觉得这不是一个腾讯在职的人的能做出来速度（但我没去过腾讯，或许他是真的这么有时间）很难不然我觉得他就是在腾讯专门做对外营销的，甚至应该还有策划团队才是，不然这么多项目点子，他还在腾讯真的屈才啊！

在其他地方你能看到谁也是这么快就产出一个项目的人？几乎没有吧？

因此，我觉得 **「鱼皮」不是一个人**

---

## 即使是一个人，他也不是真的做开源的

ok 我们先不管这个，但我认为他也不是做开源的，永远都不管issues，这个不太像是做开源的吧？commit messages 让人不知道在干嘛 不是 first commit 就是个人式计数commit message，不太让我觉得像是认真做开源的。

> 一般来说开源项目无论是 commit message 或者是 PR title 都应该需要遵循 [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) 规范，这不仅是为外来的开发者好，也是为自己好，可以让自己知道自己到底修改了多少次。

你要是跟我急，说他没经验我更不理解了，一个做了这么多成熟项目的人，拿到了这么多个 star 的人，真的没经验吗？没经验这个借口是不攻自破的。

<details>
  <summary>一堆的 issues 节选</summary>


<img width="600" alt="501c041194f336077ca5db3795043633" src="https://user-images.githubusercontent.com/62133302/200162226-a51c4229-307e-40a5-945e-aab141ca86c7.png">

> URL: https://github.com/liyupi/sql-father-frontend-public/issues


</details>

他不是不在线，，sql father刚刚才出诶，issues这就不管了。有bug 就修 没时间我觉得标注个bug babel也好，issues 不成立就丢个invalid babel 就 wonfix 关闭，就标注一下做个这个很难吗？

这是 Issues 方面，还有 PR 方面

<details>
  <summary>PR 节选两个具有代表性的</summary>


<img width="600" alt="165f2801324f5822de08bd37220ae4df" src="https://user-images.githubusercontent.com/62133302/200162297-9437d190-7eb2-40cf-b56f-14e2705f016a.png">

> - https://github.com/liyupi/yuindex/pull/52
> - https://github.com/liyupi/yuindex/pull/56


</details>

就这俩举例，人家都改完了，他又不理了，就搞个changes request摆在那里，这是做开源的？

---

所以说，他就是腾讯的营销，单纯就是想让编程平民化，多点人来996压榨的手段罢了...

忘说了，这鱼皮还推荐你去知识星球呢，看截图都是好评诶！就是这费用嘛，不是很多，也不是很少，也就没几顿饭而已哈哈。人家天天赚n桶金，你就一天就搞没几天的饭桶钱咯～

要我说啊

<img width="1183" alt="image" src="https://user-images.githubusercontent.com/62133302/200162896-11f476a3-8998-49b2-b08a-d36bff12900d.png">

> Repo: https://github.com/liyupi/rubbish-yingxiaohao

---

## 更新：仓库的所有权转让了

<img width="1379" alt="image" src="https://user-images.githubusercontent.com/62133302/200163976-3eece1ee-d07c-4d81-8965-6eee2fffac2e.png">


有关这个事情的全部，你可以看看我的朋友 [@Justin Sun](https://github.com/jsun969) 写的这篇文章：https://github.com/jsun969/rubbish-yingxiaohao/tree/article

或者在掘金上你也可以找到它 https://juejin.cn/post/7163065667590029348

V2EX 上也发表了：https://www.v2ex.com/t/893205

最新的情况是 这个仓库的所有权转让了，全部star还有watch都不见了，包括PR记录也没了，从 liyupi/rubbish-yingxiaohao 转到 Forest1sland/rubbish-yingxiaohao 了，至于这个 Forest1sland 是什么奇怪的账号我就不探究了，这也不关我事，至少他就是玩不起了。

讲真的，除了转让所有权之外，最让我感到意外的是他revert了所有的commit，并且 **所有的 PR、Issues 都消失了，所有的贡献者不复存在** 。你想一下这是做开源项目的吗？

别人代码提交 他全然不管，但是修改一个影响到他的利益，他恨不得全网封杀你，那个 PR 关的比谁都快，鱼皮哥，真的，别装了。你只写新项目，却不接受 PR，那你搞什么开源呢？

> 我是说大部分，有一丢丢丢丢丢 PR 和 issues 是理的，至于这个量嘛...我觉得我便秘好了他都没回复一个..


---

## 更新：遇到了一个比较迷惑的 issue


<details>
  <summary>
  https://github.com/liyupi/mianshiya-public/issues/20
  </summary>
  <img width="1619" alt="da8904e9f44cc3cec25aa2449eee3c27" src="https://user-images.githubusercontent.com/62133302/200229891-19fdeae4-37b1-4bb2-ab67-8175b514c25b.png">
</details>


在这里，我抛开一切对他的评价，但从他的回复看看：

<details>
  <summary>
  https://github.com/liyupi/mianshiya-public/issues/20#issuecomment-1078909120
  </summary>


  ![b01ad53dcf2a5aff59258744d65d1fc6](https://user-images.githubusercontent.com/62133302/200230011-c9900f4f-4b8c-4540-b45e-c73e7c4d24e3.png)

</details>

这合理吗？这很明显就是大小写的问题，这还是后面有位热心的用户回复的问题。由此可见，**鱼皮到底有没有仔细看报错？** 还是说，**他压根就不懂？（我希望不会是这种的）**

后续，也有用户开启了 PR，就是修复这个问题的 https://github.com/liyupi/mianshiya-public/pull/36 我觉得鱼皮不可能看不到，荆棘发的 PR 他能这么快就关闭，这就表明他是在线的。所以我很迷惑这种行为，为什么有修bug的PR不去合？

还是这个项目 [这个 PR Closed 的列表里面](https://github.com/liyupi/mianshiya-public/pulls?q=is%3Apr+sort%3Aupdated-desc+is%3Aclosed) 我没看错的话，closed的都是增加贡献者的 PR 吧？[开的 PR 列表里面](https://github.com/liyupi/mianshiya-public/pulls?q=is%3Apr+sort%3Aupdated-desc+is%3Aopen) 就上面提到的这一个，他就是不合，很让我迷惑啊

## 更新：再来说说我对知识付费的看法

我先说明：我也做过收费的东西（ Typecho 主题 ）虽然很小，但也是收费的，这是肯定的。

我认为优质的知识是可以让我去主动付费的，这一切都来自于缘分。你可以说我迷信啥的，但是 于我个人而言，我并不喜欢将付费的知识强加在他人身上，做每一样东西都要求收益，将付费明面地贴在 README 上，我并不喜欢。

这是我的看法，也只是我的看法。

## 更新：我真的写了很多帖子吗？

事实上并没有，你可以在全网公开搜，除了这一次的事件，我在外面没有说过任何关于他的事情。我知道我自己不行，所以我不敢怎么去说他。但是我实在是看到觉得很郁闷，很奇怪，实在没有办法只好写了这一篇小文。

**我认为，我没有在浪费时间，通过这次的事件也让我知道了有多少水军，分布在哪里，有多少看清楚本质的大佬。我认为，这篇文章，我写的值得**

呀！(o^^o) 使用 CronJob 同步 GitHub 用户的活动

GitHub：https://github.com/wibus-wee/github-event-discord-listener （欢迎 Star 🌟！）

## 事情的起因

![截屏2022-11-02 07.29.16](https://cdn.my-api.cn/user/w/asset-pic-picgo/2022-11-202211020729606.png)

是这样的，我和 [@荆棘](https://github.com/jsun969/) 大佬创建了一个新的 Discord 服务器，另外一个大佬说了一个有点意思的东西：同步用户活动，在翻找 GitHub 无果后，我只好自己手写了

## 想法原理

GitHub 原本是有一个 Webhook 功能的，可以在特定的事件发生时，向指定的 URL 发送一个 HTTP 请求。但是我们需要监听用户活动，第一：我们不可能要每一个用户去配置一个 Webhook，这很明显不可行，并且有可能 private 仓库的活动也会被传播，第二：用户活动的更新反馈是无法被 GitHub 主动触发的。

结合上面的问题，我只好暂时使用 cronjob 来定时向 GitHub 发送请求，获取用户活动, 获取活动有个 API：https://api.github.com/users/${username}/events/public 拿他就完事儿了！

为了实践~~万物皆可 js~~的理论，加上我很懒的问题，就使用 node v18 的 fetch 特性来做请求好了。

## Coding 部分

正好，GitHub Action 支持 `schedule` 字段，我们把它设置为 15min 好了

```yml
name: "Event Checker"
on:
  push:
    branches:
      - main
  schedule:
    - cron: "*/15 * * * *"    # every 15 minutes
  workflow_dispatch:
```

如果你并不希望 push 的时候被触发，那就删掉这个字段就好了。

### 如何发出最新的活动？

我目前的想法是利用文件储存最新的活动`id`，根据~~微略的计算~~，我发现新的 Event ID 都恒大于旧的 Event ID，那我只需要保存最新的 Event ID 比对即可

> 但不是什么都要广播的，我们只决定广播 `Issues`, `PR`, `Star (Watch)` 活动
>
> 那么这个所谓的 “最新”的 Event ID 也应该只是这三个活动当中的最新活动ID，而不是全部的最新活动 ID

---

为了不想装 node_modules 我全部选择原生的库（fs, fetch)，这样就可以很容易被调用了。

```js
const jsonFile = require('./latest.id.json');
const subscribersFile = require('./subscribers.json');
```

先导入两个文件，一个是最新ID的保存，另一个是订阅用户的username储存，他们大致像是这样的：

```json
// latest.id.json
{"jsun969":"24954043300","wibus-wee":"24969877605",}

// subscribers.json
[ "wibus-wee", "jsun969", ]
```

这样导入的就是一个 Object，我们也不需要使用 `JSON.parse()` 等方法了

为了方便发送信息，我们直接定一个产生出 body 的方法

```js
const body = (content, username) => {
  return {
    content,
    username: `[GitHub] ${username}` || "GitHub",
    avatar_url: username ? `https://github.com/${username}.png` : "https://github.githubassets.com/images/modules/logos_page/GitHub-Mark.png",
  }
}
```

不但是 content，还使用了 GitHub User 上传的头像，这样发出来或许会更形象一点呼呼呼

~~由于写得匆忙，我也来不及想那个好那个不行了~~，我直接就用 forEach 获取一下每一个 username 之后立即发送讯息，并且保存好最新的ID（如果有的话）

```js
usernames.forEach(async function (username) {
  // ...
})
```

但需要注意的是，我们前面讲了不是什么都要广播的，“最新”的 Event ID 也应该只是这三个活动当中的最新活动ID，而不是全部的最新活动 ID，我选择继续跑这个数组，利用 `switch-case` 判断 type，如果他是 `IssuesEvent`, `PullRequestEvent`, `WatchEvent` 中的任意一种，就将这次活动的id存入进去，以及把内容 return 出来，如果不是，就return个空的值。

> 代码中，我对某些变量定义使用了 var，实际上我并不建议使用 var，这是一个将近被弃用的关键词了，我们只有在特殊情况才会用到它，至于这个地方... ~~可能算吧~~

最后 `filter` 方法将空的内容过滤一下就好了，接着用 `fs.writeFile` 写下文件就 ok 👌 了. 不过最好用 sort 排序一下，取最大的值存入进去（最新的）

欢迎来到 [GitHub](https://github.com/wibus-wee/github-event-discord-listener) 给我 Star 一个！

要知道 Emoji 中的编码，我们就得先知道「Unicode」这个玩意，在官方网站中有这么一句话：「Unicode 为所有的字符都提供了一个独一无二的数字，不论在哪个平台，不论在什么项目，不论是怎么语言。」

> *Unicode provides a unique number for every character,
> no matter what the platform,
> no matter what the program,
> no matter what the language.* -- Unicode Information

## 什么是 Unicode？

最简单的来说，他就是使用英文+数字+"+"来表示我们日常的字符的，譬如说这个文章我们就可以使用 Unicode 全部写出来，当然就不是给人看的了，为什么？

Unicode 标准定义了一个 code space，一组从 0 到 10FFFF[^1] 范围的数值被称为「代码点」, 并且会表示为 U+0000 到 U+10FFFF

> 「U+」后面跟的十六进制的代码点值，前面有前导零[^2]，代码点值至少四位数
>
> 比如说 `U+00F7` 表示 `÷` ，代码点 U+0041 是十六进制数 0041（等于十进制数 65）代表 Unicode 标准中的字符“A”，而 U+13254 （不是 U+013254，没有前导零）表示的是某一个埃及象形文字

但是在众多代码点中，从 U+D800 到 U+DFFF 的代码点，是不允许编码有效字符的，它将被 Unicode 保留。

U+D800–U+DBFF（1024 个代码点）范围内的代码点称为高代理代码点，而 U+DC00–U+DFFF（1024 个代码点）范围内的代码点称为低代理代码点码点。1高1低在 UTF-16 中形成一个代理对，以此来表示大于 U+FFFF 的代码点。

在排除代理项和非字符后，有 1,111,998 个代码点可以使用。

## UTF-X 都是些什么？

UTF-8 是一种变长的 Unicode 编码方式，它可以使用 1 到 4 个字节表示一个符号，根据不同的符号而变化字节长度。

UTF-8 的编码规则很简单，只有二条：

1. 对于单字节的符号，字节的第一位设为0，后面7位为这个符号的 Unicode 码。因此对于英语字母，UTF-8 编码和 ASCII 码是相同的。
2. 对于 n 字节的符号（n > 1），第一个字节的前 n 位都设为1，第 n + 1 位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的 Unicode 码。

UTF-8 编码的一个例子：

| Unicode 码点 | UTF-8 编码（二进制） | UTF-8 编码（十六进制） |
| :--- | :--- | :--- |
| U+0000 | 00000000 | 00 |
| U+0007 | 00000111 | 07 |
| U+0041 | 01000001 | 41 |

UTF-16 是一种 Unicode 的编码方式，它使用 2 或 4 个字节来表示一个符号（字符）。UTF-16实现方案则介于UTF-8和UTF-32之间。对最常用的基本平面中字符的存储空间进行了压缩，使得汉字只需要两个字节就可以存储。

但是UTF-16又是怎么解决字符存储的时不同字符的边界问题的？这就需要用到代理对的概念了。

前面提到代理对的概念。UTF-16 将代理对的第一个代码点的值减去 0xD800，将第二个代码点的值减去 0xDC00，然后将两个结果合并，得到一个 20 位的二进制数，加上 0x10000，就得到了原来的代码点的值。

UTF-16 编码的一个例子：

| Unicode 码点 | UTF-16 编码（二进制） | UTF-16 编码（十六进制） |
| :--- | :--- | :--- |
| U+0000 | 0000000000000000 | 0000 |
| U+0007 | 0000000000000111 | 0007 |
| U+0041 | 0000000001000001 | 0041 |

这样，UTF-16 就可以使用 2 个字节来表示 U+0000 到 U+FFFF 之间的字符，而对于 U+10000 到 U+10FFFF 之间的字符，就需要使用 4 个字节来表示了。这样就可以保证所有的字符都可以被编码，而且编码后的字节长度也是固定的。

当然，除 Unicode 以外，还有很多不同的编码标准（如 GBK 等）但本文不详细说他们了。

## 讲讲 Emoji 的编码

Emoji 我们日常都会使用，比如 😊 它们都是 Unicode UTF-16 编码的，在 UTF-8 编码中，它们会被编码成 8 个字节，这样的编码方式就会导致 Emoji 的存储空间变大。

![截屏2022-10-31 08.41.33](https://cdn.my-api.cn/user/w/asset-pic-picgo/2022-10-202210310841399.png)

从U+1F300开始，存放的这些小表情就是emoji表情。

> 但需要注意的是，Unicode 本身是不支持 Emoji 的，Emoji 是由 Unicode 和 Emoji 两部分组成的，Unicode 只是规定了 Emoji 的编码，而 Emoji 是由 Apple、Google 等公司自己定义的。
>
> 如果用户的系统没有实现某个emoji表情的渲染，就会显示成一个空方框。

| ![笑脸](https://cdn.my-api.cn/user/w/asset-pic-picgo/2022-10-202210310856807.png) | ![白发男子](https://cdn.my-api.cn/user/w/asset-pic-picgo/2022-10-202210310858388.png) | ![撅嘴的女人](https://cdn.my-api.cn/user/w/asset-pic-picgo/2022-10-202210310858808.png) |
| :----------------------------------------------------------: | :----------------------------------------------------------: | :----------------------------------------------------------: |
|                           一个码位                           |                           三个码位                           |                           四个码位                           |

我们看到，一个 emoji 表情是变长存储的，而且一个表情可占用多个码位组成。而其中这个白发男人，是由三个码位组成: U+1F468 U+200D U+1F9B3，而这个白发男人的 emoji 标签是 `People & Body`，`Person`。这表明，U+1F468 表示的是人，U+200D 表示的是连接符，U+1F9B3 表示的是白发男人。这些表情的渲染又有什么规则呢？

在 Unicode 官方文档中，有提到[相关的内容](https://www.unicode.org/reports/tr51/#Emoji_Properties_and_Data_Files) 我简单给大家总结一下：

1. 一个 emoji 表情的渲染是由多个码位组成的，这些码位的值是连续的，且值的范围是在 U+1F300 到 U+1F5FF 之间的。
2. emoji 标签由两部分组成，第一部分是 emoji 的类型，第二部分是 emoji 的子类型，比如 😊 的 emoji 标签是 `Smileys & Emotion`，`Face Smiling`。 emoji 标签的具体内容可以参考[这里](https://www.unicode.org/Public/emoji/13.1/emoji-test.txt)。

有一个很有趣的现象，就是 emoji 表情的渲染是由多个码位组成的，但是这些码位的值是连续的，且值的范围是在 U+1F300 到 U+1F5FF 之间的。这样的设计，就导致了 emoji 表情的渲染是有规律的，比如我们可以通过下面的代码来生成 emoji 表情：

```js
function generateEmoji() {
  const start = 0x1f300;
  const end = 0x1f5ff;
  const code = Math.floor(Math.random() * (end - start + 1)) + start;
  return String.fromCodePoint(code);
}
```

甚至，你可以用 js 的 replace 方法来替换 emoji 表情，假设我们要替换一下 👨‍👩‍👧‍👧 中的孩子，要把它变    👨‍👩‍👧‍👧 ，我们可以这样做：

```js
'👨‍👩‍👧‍👧'.replace('👦', '👧'); // 👨‍👩‍👧‍👧
```

## 参考材料

- https://blog.51cto.com/u_11887782/5788627
- https://www.unicode.org/standard/principles.html
- https://www.unicode.org/reports/tr51/#Emoji_Properties_and_Data_Files
- https://en.wikipedia.org/wiki/Unicode#Architecture_and_terminology

[^1]: 此处使用的是十六进制数字系统，它使用 16 个不同的符号，最常见的是符号“0” - “9”表示值 0 到 9，“A”-“F”表示值从 10 到 15。
[^2]: 前导零是位置表示法中数字字符串中第一个非零数字之前的任何 0 数字。例如，詹姆斯邦德的著名标识符 007 有两个前导零。

浅谈 Emoji 中的 Unicode 编码

## 比较两个集合的长度

如果集合1的长度小于集合2的长度，意味着集合1有可能是集合2的子集（如果集合1的元素都在集合2中）

反之，意味着集合1有可能是集合2的父集（如果集合2的元素都在集合1中）

但是无论如何，判断长度后都需要判断是否有交集


```ts
function compareLength(collection1, collection2) {
    if (collection1.length < collection2.length) {
        return -1;
    } else if (collection1.length > collection2.length) {
        return 1;
    } else if (collection1.length === collection2.length) {
        return 0;
    } else {
        throw new Error('compareLength error');
    }
}
```

## 判断交集

如果有交集，那么就需要判断是否是真子集or子集（无非就是查看集合1中的元素是否有在集合2中）

```ts
function haveIndex(collection1, collection2) {
    let result = false;
    for (let i = 0; i < collection1.length; i++) {
        //如果在集合2中找到了集合1的元素，那么就有交集 indexOf 是查找元素的位置,如果找不到返回-1
        if (collection2.indexOf(collection1[i]) !== -1) { // collection2 的长度大于集合1的长度
            result = true;
            break;
        }
    }
    return result;
}
```

## 判断是否有交集

交集有两种情况：

1. 集合1与集合2相同，集合1与集合2有交集
2. 集合1与集合2不相同，集合1与集合2有交集，那这个情况就需要考虑谁是谁的子集

如果他们都没有交集，那么就是不相交，啥也不是

> 需要注意的真子集和子集的区别：
> 
> 子集就是一个集合中的全部元素是另一个集合中的元素，有可能与另一个集合相等
> 
> 真子集就是一个集合中的元素全部是另一个集合中的元素，但不存在相等

```ts
function hasIntersect(collection1, collection2) {
    // 先判断长度
    if (compareLength(collection1, collection2) === 0) { //长度相等

        // 因为长度相等，因此不需要判断是否是真子集or子集，绝对是真子集
        return haveIndex(collection1, collection2) ? "子集" : "啥也不是";

    } else if (compareLength(collection1, collection2) === -1) { // 1<2

        return haveIndex(collection1, collection2) ? "真子集" : "啥也不是";

    } else if (compareLength(collection1, collection2) === 1) { // 1>2
        return haveIndex(collection2, collection1) ? "父集" : "啥也不是";
    }
    return "啥也不是";
}
```

## 运行

```ts
const collection1 = [ 1, 2, 3, 4 ];
const collection2 = [ 1, 2, 3, 4, 5 ];

console.log("collection1: " + collection1)
console.log("collection2: " + collection2)
console.log("子集情况: " +
            "collection1 是 collection2 的" + hasIntersect(collection1, collection2));
```

判断两个集合子集/父集关系

## Introduction

Both of them have a meaning: learning again. But how many differences between these two words?

> We just talk about the meanings of words as <u>verbs</u>.

## re·vise /rɪˈvaɪz/

1. **To prepare for an exam by looking again at work that you have done.**
2. To change sth, such as a book or an estimate, in order to correct or improve it
3. To change your opinions or plans, for example because of sth you have learned

## re·view /rɪˈvjuː/

1. a report on a subject or on a series of events 
2. **a lesson in which you look again at sth you have studied, especially in order to prepare for an exam**
3. an examination of sth, with the intention of changing it if necessary
4. a report in a newspaper or magazine, or on the Internet, television or radio, in which sb gives their opinion of a book, play, film/movie, etc.; the act of writing this kind of report

---

Their meanings seem to be the same. But they appear in different people.

> ***“revise”*** is often used by people who use British English
> 
> ***“review”*** is used by American.

(EN) Revise or Review ?

在 Core GitHub 上有一个 Draft PR, [Pull Request #309](https://github.com/nx-space/core/pull/309)，里面已经基本列举了这次重构的所有计划以及修改注意事项.

## 到底为什么要专门起一个 PR 来修改？

说到底还是架构的变化

### 原本的 Core

只有一个程序，里面的全部模块最后都会被导入进 AppModule，这样导致的问题将会是：

- 如果这个项目一开始就是只有一个人写的，那后续的更新也只能是那个人来更新
  - 目录与目录间紧密关联。
  - 系统间接口调用的方式耦合紧密导致难以维护
- 对系统的任何修改都必须整个系统一起重新部署或升级
- 在系统负载增加时，难以进行水平扩展
- 当系统中一处出现问题，会影响整个系统

### 未来的 Core

使用微服务架构，优点有很多：

- 一个仅负责一项很明确业务的微服务，肯定比一个复杂的系统更容易理解
- 对一个微服务进行修改时，能够更容易分析到这个修改到底会产生什么影响
- 可以更频繁的去更新核心，通过很低的集成成本，快速的发布新的功能
- 适合应对系统业务增长，扩展性对比单一服务高了很多
- 可以通过组合已有的微服务以达到功能重用的目的
- 一个微服务的异常不会导致其它微服务同时异常

但，**缺点也是有的：**

首先，程序的复杂度会变高，代码逻辑会更加复杂，因此需要一个设计良好的监控系统对各个微服务的运行状态进行监控。由于服务与服务之间需要通信，不可避免的就是通信时延导致的响应问题

我认为利大于弊，对我们来说，这将会是一次革命性的更新！不过到那个时候可能这个博客又得重来一遍了😂

NEXT 为什么要开始重构？

NextJS 如何有效地减少 First Load JS 的体积大小

> 先说结果：共减少了 `580.8 kb` 的 First Load JS 大小！

写前端的时候，功能只写了一点，原以为体积很小，部署后发现进入的时间越来越慢，我开始了深深的思考...

最简单的就是使用 Google LightHouse 进行检查，分析告诉我，我加载的 JS 文件太大了，我只好返回去看看编译的时候返回的大小情况

当我运行 `next build` 的时候，它却告诉我一个十分悲惨的事实：

```
Route (pages)                              Size     First Load JS
┌ λ /                                      706 B           111 kB
├   /_app                                  0 B             108 kB
├ λ /[pages]                               967 B           691 kB ⚠️
├ λ /404                                   188 B           108 kB
├ λ /category/[slug]                       1.05 kB         133 kB
├ λ /links                                 2.12 kB         559 kB ⚠️
├   └ css/5daf79f472e2d72a.css             1.76 kB
├ λ /posts                                 1.08 kB         133 kB
├ λ /posts/[category]/[slug]               1.13 kB         691 kB ⚠️
└ λ /tag/[name]                            1.01 kB         133 kB
+ First Load JS shared by all              119 kB
  ├ chunks/framework-8792ff04d9bb21fc.js   45.7 kB
  ├ chunks/main-465434c0b66bfe41.js        31.1 kB
  ├ chunks/pages/_app-8f9e59e58813e545.js  29.8 kB
  ├ chunks/webpack-06f027d2973c0918.js     1.01 kB
  └ css/82c644df5d8e11c0.css               11.7 kB
```

`/[pages]` 居然达到了惊人的 700 kb。 这都接近 1M 了，再加上我的服务器在海外，**加载速度能不慢吗？**

## 使用 Analyze 分析问题所在

为了发现问题所在，我只能安装 `@next/analyze` 去分析到底是哪些文件这么丧心病狂

```js
// in cmd
pnpm i -D @next/bundle-analyzer

// in next.config.js
if (process.env.ANALYZE === 'true') {
  plugins.push([require('@next/bundle-analyzer')({ enabled: true })])
}
```

接着运行起 `ANALYZE=true next build` ，等一会儿就能在浏览器看到具体情况了

![analyze ui](https://cdn.my-api.cn/user/w/asset-pic-picgo/2022-08-202208211717655.png)



> 👆这张图片是后来截的图了，之前的忘记截了

将鼠标放置上去即可看到这个文件的 Size，首先先优化一下 */_app*：

## 移除/合并多余的组件

在 `_app.tsx` 中我的 Layout 是这么写的：

```tsx
import Header from '../components/layouts/Header'
import Footer from '../components/layouts/Footer'
import MainLayout from '../components/layouts'

function App({ initialData, Component, pageProps }) {
  return (
  	<>
    	<Header />
    	<main>
      	<div className="wrap min">
  	      <Component {...pageProps} />
      	</div>
    	</main>
   	 	<Footer />
    </>
  )
}
```

很明显，写在 App 中的代码非常多余，`Header`, `Footer` 这些根本就没有需要 Props 的就不应该出现在这个地方

我主要变化的组件只有 `<Component />`。应该将那些组件放到一个文件里面实现。

除了这个还有一种情况： **使用了第三方的 layout 组件**

换句话说，就是建议你**自己实现**它，而不要使用第三方组件，第三方组件为了兼容各方，会写入许多你获取用不上的内容（确信）

### In AppLayout.tsx

```tsx
export const AppLayout: FC<React.PropsWithChildren> = ({ children }) => {
  // ...
  return (
  	<>
    	<Header />
    	<main>
      	<div className="wrap min">
			{children}
      	</div>
    	</main>
   	 	<Footer />
    </>
  )
}

// const Header: FC....
// ...
```

### In _app.tsx

```tsx{117,118,119}
import AppLayout from '../components/layouts/AppLayout'

function App({ initialData, Component, pageProps }) {
  //...
  return (
    <AppLayout>
      <Component {...pageProps} />
    </AppLayout>
  )
}
```

## 动态导入组件

动态导入使用的是 nextjs 中自带的模块，并不需要安装，在文件里面引入即可。我那500多KB的减少，就是靠的这个模块. 使用 `dynamic` 导入组件不会包含在页面的 First Load JS 中

### 毅然选择动态导入你认为会有影响的组件

前天刚给前端添加了一个 Commander 的 Feature，使用的是 cmdk 项目，我自己心知肚明这个是导致 First Load JS 偏大的一个原因，由于考虑到用户一进来并不会立即使用到这个 Commander，于是我打算将它使用 `dynamic` 动态导入.

```tsx
// layouts/AppLayout.tsx
// 因为他并不需要 Props，也没有必要展现在 _app 里面，所以也是写在 AppLayout 里的
const Commander = dynamic(() => import("../../widgets/Commander"), {
  ssr: false
})

const AppLayout:.... ({children}) => {
  return (
    <>
      <... />
      <Commander />
    </>
  )
}
```

就只是换了一种写法，将 `import Commander from '...'` 变成了 `dynamic(() => import("..."))`，调用它还是一样的。那这里就简单说一下dynamic的第二个参数：

- `suspense`: 与 `<Suspense fallback={``} />` 同用，页面会先渲染 Suspense `fallback`，import 的组件会被解析后才进行渲染
- `ssr`: 如果 false 就会在客户端动态加载这个组件，如果组件依赖于浏览器 API (`window`)，那你应该把这个设置为 `false`

> 官方的解释在这里： https://nextjs.org/docs/advanced-features/dynamic-import

最后在build阶段返回的 First Load JS 大小果然有所改变：*108 kB --> 95.5 kB*

---

由于文章与页面的代码相差并不多，那就直接把目光聚集到 *[pages]/index.tsx* 中，首先要找到到底是什么导致了 First Load JS 这么大的。你问我方法...**真就排除法呗** 😂

### 排除后动态导入有可能会影响的组件

```tsx
import { GetServerSideProps, NextPage } from "next";
import Head from "next/head";
import Link from "next/link";
import { useEffect, useState } from "react";
import { useSnapshot } from "valtio";
import Markdown from "../../components/Markdown";
import SEO from "../../components/others/SEO";
import Comments from "../../components/widgets/Comments";
import appState from "../../states/appState";
import { apiClient } from "../../utils/request.util";
import { isClientSide } from "../../utils/ssr.util";
```

不知道你是否觉得其中的 *Markdown*, *SEO*, *Comments*，都非常可疑，为了解决我的疑惑，我直接注释掉了其中的一个引入和使用了它的代码。结果非常明显，当我注释了 Comments 后, `678 kB --> 546 kB`，于是我立马选择了动态导入。那其实这三个都是带有较大影响的，我就不一一举例了。

最终把这些都进行动态导入后，我得到的结果是这样的：

```
Route (pages)                              Size     First Load JS
┌ λ /                                      3.61 kB        111 kB --> 99.7 kB
├   /_app                                  0 B            108 kB --> 96.1 kB
├ λ /[pages]                               1.08 kB        691 kB --> 97.2 kB
├ λ /404                                   188 B          108 kB --> 96.3 kB
├ λ /category/[slug]                       774 B          133 kB --> 96.9 kB
├ λ /links                                 746 B          559 kB --> 96.8 kB
├ λ /posts                                 801 B          133 kB --> 96.9 kB
├ λ /posts/[category]/[slug]               1.24 kB        691 kB --> 97.3 kB
└ λ /tag/[name]                            732 B          133 kB --> 96.8 kB
```

你可以看到，都有不同程度的减少.

### 什么组件可以动态导入但什么组件不行？

1. 如果用户不是立马就需要使用/看到的，**可以**
2. 如果有影响交互效果的，**不可以**
3. 动态导入后，大小不降反升的，**肯定不可以啦！**
4. 详情页中输出详情的，**可以，但我不太建议**

Single 主题与单身狗 -- 新的 NEXT 主题上线！

**感谢保罗所编写的 Single 主题！** 

经过了长达一周的开发，Single 成为了我们的目前第二个官方主题，现在站点就是 Single 主题啦！你可以在这里看到 [与本文同样的文案](https://nx.js.org/blog/new-theme-single/)

**GitHub Repo Page(欢迎 Star 🌟！): https://github.com/nx-space/nx-theme-Single**

## 主题亮点

昨今给 Single 加了一个小功能，你只需要使用 *command(或 control)* + *K*，即可打开这个小功能。你可使用键盘进行对应操作！里面的一些功能还在调试和更新中... 我想对 Single 做的魔改还有更多哈哈哈，慢慢改进吧！

> 不知道你对这个主题的魔改有什么想法呢？可以在评论区或者[GitHub Issues](https://github.com/nx-space/nx-theme-Single/issues) 跟我说说呀！

## 关于开源许可

本项目采用 AGPLv3 开源协议进行授权，衍生项目必须遵守相同的协议，**必须开源**。严禁将本主题进行二次售卖。在使用转载、移植等方式二次发布本主题时，需要保留本主题的版权说明，例如 **“移植自奇趣保罗的 Typecho 主题：Single”**。如未遵守本协议使用，作者将拥有追究的权利。

原创不易！如果喜欢本项目，请 Star 以示对保罗的支持～ 同时欢迎前往 **[保罗的博客](//paugram.com)** 提供赞助，谢谢您！

插件系统 其实见的并不少了，Chrome, Visual Studio Code等等都有自己的一套插件系统，这不是自己也在写一个博客系统嘛，想着实现插件系统会好玩点，本文主要是通过阅读各路大佬的文章，最终总结出来的一些东西

## 为什么要做一个插件系统？

作为一个系统开发者，开发系统考虑的事情有所局限性，其实现的「features」或者对于一些人来说并不够，他们需要更多的额外功能，但是由于整一个系统的项目结构较复杂，其他人来维护的成本相对来讲会较高。那这个时候就需要使用一个插件来实现那些额外的功能。

当然插件也可以将系统功能拆分为松耦合的子模块，分而治之。

## 设计插件&系统？

### 插件有什么

如 VSCode 和 Chrome 的插件，他们内部都自带一个核心配置引导文件：`package.json` 或 `manifest.json` 

#### Chrome

比如在 Chrome 中的插件主要有两个配置字段：`background`, `content_scripts`

这个是 配置文件

```json
// https://developer.chrome.com/extensions/manifest
{
    // ...
    // 会一直常驻的后台JS或后台页面
    "background": {
      "persistent": false,
      "scripts": ["background_script.js"]
    },
    // 需要直接注入页面的JS
    "content_scripts": 
    [
        {
            // "<all_urls>" 表示匹配所有地址
            "matches": ["<all_urls>"],
            // 多个JS按顺序注入
            "js": ["js/content-script.js"]
            // 代码注入的时间，可选值： "document_start", "document_end", or "document_idle"，最后一个表示页面空闲时，默认document_idle
            "run_at": "document_start"
        }
    ],
    // ...
}
```

在 Chrome 中 它提供了一个全局变量，上面有很多的生命周期钩子，比如说 runTime, onMount, onInstall

```javascript
chrome.runtime.onInstalled.addListener(function() {
    chrome.contextMenus.create({
      "id": "sampleContextMenu",
      "title": "Sample Context Menu",
      "contexts": ["selection"]
    });
  });
  chrome.bookmarks.onCreated.addListener(function() {
    // do something
  });
  chrome.runtime.onMessage.addListener(function(message, callback) {
    if (message.data == “setAlarm”) {
      chrome.alarms.create({delayInMinutes: 5})
    } else if (message.data == “runLogic”) {
      chrome.tabs.executeScript({file: 'logic.js'});
    } else if (message.data == “changeColor”) {
      chrome.tabs.executeScript(
          {code: 'document.body.style.backgroundColor="orange"'});
    };
  });
```

总结一下，background中提供的功能有：

- 提供一个暴露了插件API的运行环境
- 通过事件钩子异步的通知消息
- 在事件的回调中实现数据通信

> 所以，我们发现**一个插件系统的核心是制定一套消息通信机制，同时将系统运行时的上下文进行封装，按照不同的场景需求暴露给插件。通过消息通信机制将系统和插件隔离，保证插件不会侵入原系统，通过暴露封装后的上下文内容，安全可靠的将系统资源提供给插件调用**。
>
> Zhihu.潜语.插件系统的设计 https://zhuanlan.zhihu.com/p/106183037

当一个软件系统有很多子功能模块的时候，**插件系统设计中还需要做到权限区分&分模块的资源隔离**，因此才有了 `content_scripts` 这个东西，但用 background 仅能做到运行时环境的权限管控，无法做到细粒度控制

| Type           | Accessible API                          | DOM Access   | JS Access |
| -------------- | --------------------------------------- | ------------ | --------- |
| Background     | 除 devtools                             | 不能直接访问 | 不可以    |
| Content_script | 只能访问 extension, runtime             | 可以         | 不可以    |
| Popup          | 除 devtools                             | 不能直接访问 | 不可以    |
| DevTools       | devtools, extension, runtime 中的一部分 | 可以         | 可以      |

#### VSCode

VSCode的技术栈和我的技术栈十分的接近（其实也就只是同 TypeScript 啦）因为有nodejs的运行时环境，所以相对应的，提供了一套更加复杂的插件系统。

通过 Yeoman 初始化插件项目，你在package.json中可以得到以下内容：

```json
{
    // 入口文件
    "main": "./src/extension",
    // 贡献点，vscode插件大部分功能配置都在这里
    "contributes": {
        "commands": [
            {
                "command": "extension.sayHello",
                "title": "Hello World"
            }
        ]
    },
  // 扩展的激活事件
    "activationEvents": [
        "onCommand:extension.sayHello"
    ]
}
```

`main` 定义了主入口

`contributes`声明了想要去拓展的vscode的功能（详细的contributes可以看 https://code.visualstudio.com/api/references/contribution-points ）

`activationEvents`则是告诉vscode什么时候去运行这个插件（详细的activationEvents列表可以看 https://code.visualstudio.com/api/references/activation-events ）

看看插件实现：

```typescript
'use strict';
// The module 'vscode' contains the VS Code extensibility API
// Import the module and reference it with the alias vscode in your code below
// vscode 模块提供了VS Code 插件拓展的API
import * as vscode from 'vscode';
// this method is called when your extension is activated
// your extension is activated the very first time the command is executed
// 这个方法可以理解为VS Code插件的主入口
export function activate(context: vscode.ExtensionContext) {
    // Use the console to output diagnostic information (console.log) and errors (console.error)
    // This line of code will only be executed once when your extension is activated
    console.log('Congratulations, your extension "hello-world" is now active!');
    // The command has been defined in the package.json file
    // Now provide the implementation of the command with  registerCommand
    // The commandId parameter must match the command field in package.json
    // 重点看这个注册机制！！！
    let disposable = vscode.commands.registerCommand('extension.sayHello', () => {
        // The code you place here will be executed every time your command is executed
        // Display a message box to the user
        vscode.window.showInformationMessage('Hello World!');
    });
    context.subscriptions.push(disposable);
}
// this method is called when your extension is deactivated
export function deactivate() {
}
```

- package.json 的 `contributes`字段中声明要使用commands拓展一个名为 extension.sayHello 的命令插件
- 插件active的时候在vscode.commond上注册并push到订阅器subscriptions中
- package.json 的activationEvents中声明extension.sayHello 的 调用时机为 onCommand 看到这里，各位看官应该就会发现，vscode除了上面提到的**消息通信机制**和**提供上下文**外，还**解耦了事件监听和插件加载**两个环节，从而可以提供更好的插件运行机制。

## 最为简单的方法 实现一个插件系统

根据 Chrome 和 VSCode 的插件系统，所需要做到的插件系统就需要做到：

- 控制插件的加载
- 对插件暴露合适范围的上下文，并对不同场景的上下文做隔离
- 有一套可插拔的消息通信机制，订阅&监听 

首先先在index.js模拟**插件生命周期**

```javascript
#!/usr/bin/env node
function onCreate() {
  console.log('onCreate');
}
function onStart() {
  console.log('onStart');
}
function main() {
  onCreate();
  onStart();
}
main();
```

之后可以在同级目录下 创建两个文件作为插件：`plugin-*.js`  里面就最简单地写个 `console.log()` 吧

之后 我们在 index.js 中要将插件注入

```javascript
// ...
function loadPlugin() {
  fs.readdirSync(__dirname)
    .filter(item => /^plugin/.test(item))
    .forEach(file => require(require.resolve(`${__dirname}/${file}`)));
}
// ...
```

通过运行它，你就可以收到返回了

```txt
plugin-1 loaded
plugin-2 loaded
onCreate
onStart
```

实现了插件的加载后，下面就需要实现最核心的部分了，**主文件和插件的通信**

在这个地方我们需要有一个插件注册中心（hash map）每个key代表一个类型的钩子，我们新建一个 hook.js 来实现

```javascript
// hook.js
class Hooks {
  constructor() {
    this.hooks = new Map();
  }
  add(name, fn) {
    const hooks = this.get(name);
    hooks.add(fn);
    this.hooks.set(name, hooks);
  }
  get(name) {
    return this.hooks.get(name) || new Set();
  }
  invoke(name, ...args) {
    for (const hook of this.get(name)) {
      hook(...args);
    }
  }
  async invokePromise(name, ...args) {
    for (const hook of this.get(name)) {
      await hook(...args);
    }
  }
}
module.exports = new Hooks();
```

```javascript
// index.js
#!/usr/bin/env node
const fs = require('fs');
const hookBus = require('./hooks');
function onCreate() {
  console.log('onCreate');
  hookBus.invoke('onCreate',{a: 1,b: 2}); // 这里增加了主生命周期钩子的注册,可以将主流程中的上下文变量传过去
}
async function onStart() {
  console.log('onStart');
  await hookBus.invokePromise('onStart', {a: 3, b: 4}); // 这里是一个主生命周期异步钩子的注册
}
// 这个方法传给plugin，提供给插件来调用钩子
function hook(name, fn) {
  hookBus.add(name, fn);
}
function loadPlugin() {
  fs.readdirSync(__dirname)
    .filter(item => /^plugin/.test(item))
    .forEach(file =>
      require(require.resolve(`${__dirname}/${file}`)).apply(hook) // 这里统一向钩子暴露了apply方法，作为插件主入口
    );
}
function main() {
  loadPlugin();
  onCreate();
  onStart();
}
main();
```

```javascript
// plugin-1.js
console.log('plugin-1 loaded');
function apply(hook) {
  hook('onCreate', function(ctx) {
    console.log('plugin-1 onCreate');
    console.log(ctx);
  });
  hook('onStart', function(ctx) {
    console.log('plugin-1 onStart');
    console.log(ctx);
  });
}
module.exports = {
  apply
};
// plugin-2.js
console.log('plugin-2 loaded');
function apply(hook) {
  hook('onCreate', function(ctx) {
    console.log('plugin-2 onCreate');
    console.log(ctx);
  });
}
module.exports = {
  apply
};
```

通过上面简单的几步，我们已经实现了一个简易的插件系统

## 总结

一个插件系统的核心有以下几点：

- 控制插件的加载
- 对插件暴露合适范围的上下文，并对不同场景的上下文做隔离
- 有一套可插拔的消息通信机制，订阅&监听

实现一个插件系统的步骤：

- 制定一套加载插件的机制和规则（配置 or 约定 or 注册 等等）
- 提供一个存放插件的仓库
- 统一插件入口，暴露上下文，通过回调等手段实现消息通信

## Reference

Zhihu.潜语.插件系统的设计 https://zhuanlan.zhihu.com/p/106183037

Juejin.末日沙兔.设计一个node.js插件式系统 https://juejin.cn/post/7077202852694720525

秉松博客

秉松博客

「推广」蓝易云商家机器稳定建站服务器推荐

关于B站“知名”鱼皮 UP 主，我对他的看法

呀！(o^^o) 使用 CronJob 同步 GitHub 用户的活动

浅谈 Emoji 中的 Unicode 编码

判断两个集合子集/父集关系

(EN) Revise or Review ?

秉松博客

「推广」 蓝易云商家 机器稳定建站服务器推荐

关于B站“知名”鱼皮 UP 主，我对他的看法

呀！(o^^o) 使用 CronJob 同步 GitHub 用户的活动

浅谈 Emoji 中的 Unicode 编码

判断两个集合子集/父集关系

(EN) Revise or Review ?

「推广」蓝易云商家机器稳定建站服务器推荐