在平时使用 git 时，我们时常会遇到代码需要回退的情况，一般我们使用 git 作为代码管理的工具，我们有两种方法来回退代码：
git resetgit revert两者的区别是，git revert 是提交一个新的版本来回退，将需要 revert 的版本内容再反向修改回去，会创建一个新的版本，不会影响之前提交的内容；而 git reset 是直接将 HEAD 向后移动了一下，直接回退到之前的版本，如果代码已经推到远端仓库，就无法再直接同步代码了。
我们时常需要 undo last commit，使用到的命令是：git reset --soft HEAD~
阮一峰 CSS Grid 网格布局教程
https://www.ruanyifeng.com/blog/2019/03/grid-layout-tutorial.html
因为看到需要实现 n 行 n 列的效果，自然就会想到使用 grid 布局。
grid 布局默认的放置方式是先行后列，如果要想先列后行，可以使用 grid-auto-flow: column 这个属性来实现。
hash 模式本质上就是对 history 模式的上层封装
export function createWebHashHistory(base?: string): RouterHistory {
// Make sure this implementation is fine in terms of encoding, specially for IE11
// for `file://`, directly use the pathname and ignore the base
// location.pathname contains an initial `/` even at the root: `https://example.com`
base = location.host ? base || location.pathname + location.search : ''
// allow the user to provide a `#` in the middle: `/base/#/app`
if (!base.includes('#')) base += '#'
if (__DEV__ && !base.endsWith('#/') && !base.endsWith('#')) {
warn(
`A hash base must end with a "#":\n"${base}" should be "${base.replace(
/#.*$/,
'#'
)}".`
)
}
return createWebHistory(base)
}在平时的开发过程中，分支之间的合并是十分常见的操作。我平时都是使用 merge 一把嗦，无论是开发分支到线上分支，还是线上分支到开发分支，基本都是使用的 merge。反观之前有一个后端同事，他们组内会有多人开发同一个功能的情况，他除了最终将开发分支合并到线上分支使用了 gitlab 的 merge request 去 merge，平时都是使用 rebase 来将别人的功能分支合并到自己的开发分支上。
在看到了这些情况后，我对 merge 和 rebase 有什么区别产生了疑问，正好去搞明白这两个操作究竟有什么不同。
merge 是我常用的功能，这个我自己比较熟悉，一般来说可以分成两种情况：当前分支与合并目标分支有无变更。如果当前分支就是从合并目标分支上出来的，merge 操作其实看起来就像是在合并目标分支后进行了多次 commit，commit log 也是一条直线；但很多情况下存在多人同时开发的情况，就会有变更操作，存在变更操作的时候，merge 操作会产生一条 merge 的 commit log，commit log 也会变成一条折线。很多同学可能会有强迫症介意这条折线，所以 rebase 是他们更常见的选择。
使用 CDP 模拟键盘操作时，涉及到一些组合键的 case 时，需要关注 Input.dispatchKeyEvent 中的 commands 属性。
最开始的时候我是直接通过 CDP 发送指定的组合键，并没有传 commands 属性，然后发现按键事件是成功发送了，但是并没有触发全选、复制、粘贴等操作，但我使用 playwright 去测试的时候，却发现 playwright 的模拟按键操作可以实现。我们知道 playwright 也是基于 CDP 实现的模拟操作，因此我去查看了 playwright 的源码，发现了 commands 属性是解决问题的关键。
在 vscode 里面使用 snippet 时，rfce 是 react function component export 的快捷命令，在使用这个 snippet 时，我看到和 react 相关的 snippet 都会在最上方有一行 import React from 'react'，但其实这一行删掉了也能正常运行，不删掉每次 typescript 都会报 unused import，有点烦人。
去了解了一下，在 react 17 之前 react 解析 JSX 的方式都是将 JSX 转换成 React.createElement，在 React 17 之后采取了新的 JSX 解析方式，新的 JSX 转换方式不再依赖于 React.createElement，而是通过编译器自动引入必要的代码。这意味着你可以在不显式导入 React 的情况下使用 JSX。但其实本质上 import 语句还是需要的，只是换成了编译器帮你将这一行代码补上去。
(async () => {
await new Promise((resolve) => {
console.log(1)
resolve()
}).then(() => console.log(2))
console.log(3)
})()
// 执行顺序 1 2 3
// 可以拆成几块看
await new Promise((resolve) => {
console.log(1)
resolve()
})
// 等同于
functionhttps 其实就是在 http 这个应用层协议上加了一层 TLS/SSL 的校验。
http 本身是无状态的，因此它并不安全，同时它基于 tcp/ip，数据都是明文传输，存在安全隐患。因此我们使用了 TLS/SSL 对其报文进行了加解密。
TLS 和 SSL 本质上是一个东西，前者是最初的名字，TLS 是后来基于 SSL 更新的版本。
https 会在 tcpip 三次握手后尝试建立连接，我们来聊一下 TLS/SSL 是怎么建立连接的：
在建立连接前，TLS/SSL 用的是非对称加密，即公钥和私钥都可以用于加密与解密。因此非对称加密的性能消耗会比较大。
快速 Diff 算法实测下来是性能最优的。本质上它包含了预处理的行为，借鉴了文本 Diff 中的预处理思路。
在最开始的时候，快速 Diff 先从新旧节点序列的头部和尾部分别进行比较，找到头部和尾部有哪些节点是不需要移动的，直接更新即可。在做完了这一步之后，新旧节点序列都会剩下一部分节点，这部分节点有可能可以通过直接新增节点或者卸载节点进行处理。
在做完上述处理后，剩下的节点都需要进一步的处理。无论是简单 Diff 算法、快速 Diff 算法，还是快速 Diff 算法，处理规则都是：
npm initnpm link 功能先在本地测试包代码是否正常可引入、可运行package.json 中添加 bin 字段，并指向可执行文件的路径nrm 这个库来管理我们的 npm registry，在发布 npm 包之前我们需要切换 npm registry 为 https://registry.npmjs.org/npm login，输入自己的用户名和密码，登录时可能需要二次验证码，输入即可。登录成功后调用 npm whoami 有自己的用户名输出即证明登录成功commit-and-tag-version 这个包来管理版本，这个包可以帮助我们生成 CHANGELOG 和 commit log，同时生成 git tag 方便直接定位到某个版本。
commit-and-tag-version --release-as major 下一个版本是主版本时使用（1.0.0 -> 2.0.0）commit-and-tag-version --release-as minor 下一个版本是次版本时使用（1.0.0 -> 1.1.0）commit-and-tag-version --release-as patch 下一个版本是小版本时使用（1.0.0 -> 1.0.1）commit-and-tag-version --prerelease rc 下一个版本是预发布版本（rc）时使用（1.0.0 -> 1.0.1.rc.1）npm publish 命令进行包发布操作，npm publish --tag 用于指定当前要发布包的 tag，例如我们上面提到的发 rc 包，就可以使用 npm publish --tag rc 命令。注意，直接调用命令之前，建议先调用一次 dry-run，也就是预运行一次，检查我们的操作是否有问题，方法也很简单，在命令后面加上 --dry-run 即可，即 npm publish --dry-run。在运行 dry-run 时，会看到运行完命令后 npm 会做什么事情，我们只需要检查操作是否正确符合预期，没问题的话最终执行实际的发布命令即可。