进 virtualbox 全局设置，热键里面，把下面那个 自动独占键盘 的选项去掉就行了

这种你话费到账了，然后过 48 小时假装没看到短信通知，去找客服问，看他咋回答。估计能套出他们的充值渠道。

JS ES6 提案有尾调优化，但目前好像只有用 Webkit 的 Safari 支持了，其他的 Chrome 和 Firefox 都还没实现。

@deorth 是有的，之前看一个老外的 b 站视频，植发就是把他的胡子的一部分挪到头上……
https://b23.tv/QAHcBG

举个例子，为什么会出现带备份机制的硬盘 RAID 方案？ RAID 0 不是很香？ n 块硬盘理论速度是单盘的 n 倍，那不是快到飞起？
然而现实是重要数据不敢用 RAID 0，这并不是怕你感染上什么勒索病毒文件全被锁了，因为如果你感染了勒索病毒，RAID 1 都救不了你。
不敢用 RAID 0 是因为硬盘会“自然损坏”，而一块硬盘坏了所有数据 GG 。（硬盘都是一样的，保存条件也是一样的，为啥单单坏其中一个？）

另外再想想，ECC 内存的出现又是为了什么呢？

所以，如果 CPU 不带安全机制，恐怕你在电脑前打个电话，电脑都会出错死机了……

本身顺序就是 宏-微-宏-微-宏-微-宏-微 这样交替着来的。入口肯定是宏任务，然后在入口代码中有创建微任务和宏任务的代码，入口代码执行完之后，立即执行微任务，然后再取队列里的下一个宏任务。
其实是一样的，描述的起点不同罢了。
国内说先执行微任务，再执行宏任务，这是相对于当前宏任务执行完毕之后这一个时刻来说的，当前宏任务执行完毕之后，会先清空微任务，再去执行下一个宏任务。所以是“先微任务，再宏任务”。
而你复制的这段描述的是，一个宏任务+一个微任务组成“一对”，这是相对于整个流程开头来说的，执行完一个宏任务后立即再去清空微任务，这样完成一套事件的过程。所以是“先宏任务，再微任务”。
两种说法都没问题，你要说哪个描述更准确，那我更偏向于“宏+微是一体”的“先宏后微”的描述，毕竟“先微后宏”的描述要强调是在当前宏任务执行完这个时间点。

emmmm，看上去应该没有其他泄露的地方了，你 keepAlive 关了，应该不用手动 CloseIdleConnections 了。
建议你再观察观察，因为你这个是一直在循环，你多观察一会，它是会一直增长，还是会停留在一定程度？
如果涨到一定程度就不涨了，那可能就跟 go 的垃圾回收机制有关了。

defer resp.Body.Close() 只会在 func 推出后执行，你这里一直在死循环，函数不推出，resp.Body.Close() 永远不会执行。
你这里直接把 defer 去掉应该就好了。

Linux + i3wm （或者是 sway ）

当年 Google 就是类似的手段，造成是“他们服务器不稳定”的假象，然后再过段时间就彻底 ban 了。

函数和方法看你描述的是啥，他们可以是同一个东西。
比如你写了 globalThis.foo = () => {}; 。那么 foo 就是被定义在全局环境下的一个函数，可以说 foo 是一个函数，也可以说 foo 是 globalThis 下的一个方法。foo() 就是调用 foo 这个“函数”，globalThis.foo() 就是调用 globalThis 下的 foo “方法”。
虽然本质上没有区别。
当你把它叫做“函数”的时候，一般是特指它自己本身；当你把它叫做“方法”的时候，一般特指它是属于某一个父级对象下的一个 function 类型的属性。

已经被浏览器封了吗？ Chrome Canary 90.0.4430.8，亲测隐私模式两次 ID 不一样、访客模式两次 ID 也不一样。
网页未在正常模式中打开过，直接右键隐身模式打开，测试完第一次 ID 72 43 0C 25 AE 90，关掉窗口后（但没有退出浏览器），再次重新在隐身模式打开，测试第二次 ID 28 8E 96 EE BB 6D 。
然后开启 Chrome 右上角头像里的访客模式，测试第三次 ID ED 07 C8 AD BF A5 。关掉访客窗口后再次重新打开访客窗口，测试第四次 ID 2B E9 51 B5 87 43 。

Firefox Nightly 88.0a1 ，开启了 Never remember history （火狐我主要做测试用，所以日常开着这个，干净）。未进入隐私模式，在正常模式下第一次测试 ID EC 1B 88 42 18 B1，关闭浏览器重新打开，第二次测试 ID D1 9A EB 51 D0 0C 。

CROS 是什么鬼……不是 CORS 么……😂
CORS 只能防止第三方不能再浏览器上直接请求你的接口，但不能防止第三方服务访问你的接口。
防止第三方服务访问很困难，因为你的所有限制都可以通过第三方反代解除。
加 token 、加校验都只能是提升那么一丢丢门槛而已。

一楼说的对，如果独立，则每次都应该从 master 的最新代码切出分支来开发，而不是基于上一次提交。

如果不独立，新提交依赖旧提交，那此时旧提交还在 review 过程中，如果代码不合格，出现 require change，那么此时代码可能还会发生变化，后续的提交如果基于这个提交来的话就会出现问题。所以新提交的 MR 应当标记为 WIP，等待旧提交完成 review 后确定 merge 之后，再 rebase 到最新代码解决冲突，然后再去掉 WIP 标记开始 review 。

@wellhome Dockerfile 只有第一次会从头打包，后续发布更新都不会从头打包，只会从变化的位置开始打包，之前没有变化的 Dockerfile 语句都会复用。比如：

FROM xxxxxx # 这一句每次都一样，直接复用
RUN apt-get update && apt install -y xxx # 这一句也是每次都一样，直接复用
COPY . . # 这一句开始，因为拷入的代码文件变了，所以从这一行开始后面的全部重新构建
RUN build ... # 从上一句开始从新构建

所以一般来说，安装依赖之类的语句尽可能提前，这样后续打包的时候就不会重新构建了。

实际上你可以简单理解成你的 Dockerfile 里每一条语句都是一个 commit （不正确，部分语句是会合并的），相互之间就是父子关系。具体表现在你 docker pull / push 的时候显示的那个进度条的个数。你每次构建的时候，如果这条语句前面的环境都是一样的话，并且当前这一层没有任何变化的话，那么这一条语句就不会重新执行，而是直接复用之前的构建结果。这样一来你会发现，在重新 docker push 的时候，会提示你部分层已经在服务器上存在了，只会 push 变动的部分。

@fannas 配置 config 不应该设置为运行时从环境变量里读吗？或者设置为 mount point 在运行时指定导入进去？

域名 A1 、A2 直接用 cname 解析到 B，B 用 ddns 解析到一台 ip 经常变化的服务器上。
这就已经满足你的需求了。不需要自建 CNAME 服务，也不需要 nginx 。