13 篇博文 含有标签「技术」

在本篇内容中，我们将介绍 V8 内部是如何处理 JavaScript 属性的。从 JS 的角度来看，对象（Object）和 字典（Dictionary）差不多：以字符串为键，任意对象为值。不过，在进行迭代时，会对整数索引的属性和其他属性进行不同的处理。其他情况下，不同属性的行为基本相同，与是否整数索引无关。

不过，出于性能和内存方面的考虑，V8 确实依赖于几种不同的属性表示方式。在本篇文章中，我们将解释 V8 是如何在处理动态添加的属性时提供快速的属性访问。同时，了解属性的工作原理对于解释 V8 是如何做优化的，例如内联缓存，也是至关重要的。

本文将先阐述处理整数索引属性和命名属性的区别，然后，我们将展示 V8 在添加命名属性时，如何维护 HiddenClasses 以便提供一种快速识别对象形状的方法。然后，我们将继续深入介绍命名属性是如何根据使用情况进行优化的，以实现快速访问或修改。最后，我们将详细介绍 V8 如何处理整数索引属性或数组索引。

负责人布置了个任务，写一个过滤 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

在 AWS 的 EC2 服务器上部署了这玩意，一方面分散华为云那个服务器的压力，一方面体验一下部署在服务器的流程。之前一直都是静态网页部署+云函数，比较省事。

用的 PM2 运行的接口服务，端口号是 5000 ，可以直接通过域名+端口号访问接口，但是感觉这样不太优雅，干脆用 Nginx 代理一下。让网站可以通过 /chaoxing 路径访问，让接口可以通过 /chaoxing-api 来访问。