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

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 。

@defunct9 emmmm，你这个情况的话，如果不给 app 权限，那么相当于所有第三方客户端都是不支持的啊。感觉已经无解了。

@fox233 是的，最新版本支持了世纪互联。创建配置的时候区域写 cn 就是了，详情可以参考文档。

@fox233 https://rclone.org/downloads/ 支持

rclone 试过吗？自带支持 one drive，可以配置世纪互联版本的 one drive 。
默认命令行，提供实验版的 Web GUI

如果你在 useEffect 里写了一个 async 函数：
useEffect(async () => {
await waitFor10Seconds();
return () => cleaningUp();
}, [dep]);
这样，在这个 async 函数中等待了 10 秒才会返回，而这之间你触发了 dep 的更新，请问现在的执行逻辑会怎样？
是整个组件卡着不动，等这个 Promise resolve 之后再去执行它的 cleaning up 函数吗？还是说这个 cleaning up 就不执行了？还是说把这个 cleaning up 函数加入队列，之后可能会乱序执行？或者排序后顺序执行？有时这个 Promise 也许永远不会 resolve 。
这样就会产生开发过程中的歧义。
默认约定返回 promise 的话就不支持 cleaning up ？但这就和 useEffect 本身的设计理念产生了冲突，本身的概念很简单，这又加了一种特例情况。

按照我的习惯的话，这种异步任务不会写到 useEffect 里，而是写道外面，useEffect 中只是去调用这个函数：
const fetchData = async () => {};
useEffect(() => {
fetchData();
return () => abortFetch();
}, [dep]);

另外 Promise 未处理的警告，我这里默认是没有这个警告的，我也不会去配置这个警告。
我觉得这是很正常的事情，Promise 作为一个返回值，它与其他的 return 1 、return "1" 有什么区别？在没有必要的情况下，其他的返回值你可以不接收、不处理，那为啥在没有必要处理的时候，要特别去关注 Promise 的处理呢？仅仅因为它是个“return new Promise()”？

我以为会叫 LTSD😂（以前的 LTS B 、LTS C ）……
现在用的 LTSC 的 N 版，也就是欧洲特供的版本，商店啥的都没有的版本，很干净。
不知道还会不会有 32 位的版本了，听说微软要砍掉 32 位系统？
我主要是 Linux，虚拟机里装个 LTSC N 用微信、会议啥的，考虑到这些软件都是 32 位的，所以装 32 位版本资源消耗会少一些。