负责人布置了个任务，写一个过滤 JSON 数据的方法，处理一下模型数据。递归绕的我真晕，脑子内存还是不太够。

样例数据​

规则：bosclass 值为 boqs 的是树节点，bosclass 值为 wps 的是纯数据。如果树节点的 children 是空数组，那么把树节点移除掉。树的层级是无法预估的，可能有很多层。以下是过滤后的数据：

[
  {
    "bosclass": "boqs",
    "children": [
      {
        "bosclass": "boqs",
        "children": [
          {
            "bosclass": "wps",
            "guid": "fa01a4a1f1d448a3bfb315dac41e1914"
          },
          {
            "bosclass": "wps",
            "guid": "cbf47dc52b2243c1a9d46bb046d8a13d"
          }
        ],
        "guid": "f785b4a061714dfe8fea367d12ddd29c"
      }
    ],
    "guid": "8bc6c9026bb9472f8a3e23b382f87ac1"
  }
]

如何过滤呢？首先想到的方法是递归！

当需要根据一个已有分支，来创建一个新分支并在上面开发时，这篇内容会很有用。

一般情景是，在 dev 分支开发，此时遇到了一些 bug 需要修复，要根据 dev 分支创建一个 bugfix 分支，在此分支把问题解决，然后推送并发起 pull request 将代码合并到 dev 分支。

步骤​

1.新建分支​

依据：git checkout -b <new-branch> [<start-point>]，创建并切换到 new-branch 分支，如果写上了 start-point 参数，则新分支的 HEAD 将指向它，不写则需要手动设置上游。

start-point：The new branch head will point to this commit. It may be given as a branch name, a commit-id, or a tag. If this option is omitted, the current HEAD will be used instead.

现在以远程的 origin/dev 分支为上游，新建了一个 bugfix 分支。

git checkout -b bugfix origin/dev

2.代码开发​

在 bugfix 分支进行开发。

3.设置上游分支​

现在的上游是 origin/dev，推送时会推到远程 dev 分支。 设置上游可以根据这条命令 git branch -u, --set-upstream-to <upstream> ，-u 简写比较方便，也可以使用完整参数 --set-upstream-to。

git branch -u origin/bugfix

但是这里还不能这样用，因为还没有把本地创建的新分支推送到远程，无法设置远程的上游。因此需要推送并设置上游

git push -u origin bugfix

4.推送​

可以推送到远程仓库

git push

如果没手动设置上游，需要次次都手动推送到指定分支

git push origin bugfix

在这之后，就可以在仓库看到了 bugfix 分支，可以发起合并请求了

Git Rebase 自己压根没用过，正巧公司团队要用到，学习总结一下。

使用场景​

合并提交：完成一个 feature 提交了很多次，有很多杂乱连续的 commit，团队对提交规范要求一个特性对应一次提交，此时需要合并多个提交为一个。

分支变基：多人协作开发时，用 merge 合并分支会多出一个 Merge Commit 的提交，这个提交是两个分支的最新节点的合并项。分支树呈现的是一条线从 main 分支叉出去，经过几个提交，又汇合到 main，汇合处形成了一个提交节点。团队想要让提交记录是线性的，也不想要这个多余的提交，此时适合进行变基。

举例​

有一个提交结点树，C1是首次提交，C4是 hotfix 分支第一次提交。主线是 main 分支。

               C4 <- C5
              /
C1 <- C2 <- C3 <- C6

这两天吃饱撑着，在探究为什么我的 Node 程序 Heap Usage 一直居高不下，而且会越来越多。

如何调试 NodeJS 程序​

在VSCode中可以直接调试，选择Debug，显示所有自动调试配置，选择要运行的命令，就进入了调试模式，侧栏会显示出调试的信息。可以捕获 Heap 快照，拿到 ChromeDevTool 里面导入分析。

用 Node 的 --inspect 参数搭配 Chrome 实时分析​

运行以下命令，进入了调试模式

node --inspect serve.js

在 Chrome 中打开 chrome://inspect，就可以看到 Open dedicated DevTool for Node，点击进入 Node 调试工具，就可以开始分析了。

放大问题​

很多时候，人工是难以准确排查出问题的，因为会有很多不可预料的误差，导致每次运行的结果数据不准。这时候，要放大问题，大量测试多次触发漏洞，就能很清楚的发现问题。

用 k6 对接口进行测试，运行下列测试程序 k6 run test.js

// test.js
import http from 'k6/http';

export let options = {
  vus: 100,
  duration: '20s',
};

export default function () {
  let res = http.post("http://localhost:5000/monitor/start", JSON.stringify({ phone: Math.random()*100000 }), { headers: { 'Content-Type': 'application/json' } })

  console.log(res.body);
}

通过对比前后的 Heap Size，确实管用，明显增加了将近 8MB。

接着调用了一下其他的接口，调用 processMap.clear() 把保存子进程的 processMap 清空。内存果然又降回去了，但并没有和最开始一样，而是稍稍高出了一点点。

得出结论，引用计数法回收垃圾是实实在在的，这个例子验证了它。但是仍然困扰我的是，Heap 里的 [compiled code] 这部分会一直增加，无法被回收，增加的量很小...

未解之谜：每次访问接口，即使是访问 / 路径，返回一段文本， [compiled code] 也会不断增加？

今天是第 N 次醒悟，为了确保这是最后一次醒悟，我决定在我想好前什么都不干，下定决心把什么是轻重缓急捋清楚。

真有意思，刚要理清这个道理，小案例就自己送上门来了。

在刚写完第一行字时，想去看看 Docusaurus 有没有版本更新、看看有什么新变化，避免我按着已经废弃写法的来写。真巧，访问官网出现 Connection refused 了，唤起了脑中的 “Openwrt/Passwall/SmartDNS...” 这些东西，他们开始问我：是代理的问题吗？是DNS规则没有生效吗？DNS污染？是梯子崩了吗，要不要去Telegram看看？还是Openwrt的问题，去看一下系统日志？去了解一些新梯子吧？去试一下Github能不能访问吧？...

对这些东西的极度兴趣，促使我去看看问题在哪里！我要去解决！我要去搞出延迟最低、速度最快的上网方案！

等等 ...... ，差点又上了自己的套了。我要干什么来着？不是要捋清楚轻重缓急的道理吗？这次，我好像把握住了。