我觉得楼上都进入了一个误区：不能在行尾注释就一定要在上一行注释，这没问题。但是允许在行尾注释，就不能在上一行注释了吗？肯定也可以啊！
所以，该行尾注释就行尾注释，该上一行注释就上一行注释，该用块注释就用块注释。

规则是为了代码更好看易读，统一可以方便理解。但是如果规则的出现导致代码变得不可读，那就得不偿失了！
所以，所有的代码格式化工具都会提供忽略的功能，毕竟工具都是死的，没有办法根据实际代码情况做出调整（别跟我说接入 AI，毕竟现在 AI 也不是十分可靠）。

所以，可以有规定，但是也要根据实际情况变通！
人是活的！

b 站会员……
在考虑要不要开个 YouTube 会员……
其他视频网站……额，我不愿意成为正版的受害者……

看到 25 console 计算器，我笑了😂😂😂

WSL 就挺好用的，传文件用 scp 或是 rsync

所以：
const a = async () => {
xxxxx;
return promise;
};
await a();
如果 xxxxx 里没用到 await 语句，最后 return 了一个 promise，那么 a 的 async 标志可以去掉，变成一个普通函数。因为加上 async 标志，相当于是 resolve 了两次，而去掉就相当于变成 resolve 一次。（最后调用的时候依然得 await，像这样：）

const a = () => {
xxxxx;
return promise;
};
await a();

promise 的 resolve 是递归的，只要 resolve 一个 promise，就会继续等待这个 promise。
而 reject 碰到就直接返回，如果 reject 的是一个 promise，这个 promise 不会被等待。
所以：
第一个 外层 promise 里 resolve 了一个 ( resolve 的 promise )，所以 then 的结果会递归等待里面的 promise 返回，里面的 promise resolve 了一个 42，所以得到了 “ resolve 的 42 ”。
第二个 外层 promise 里 resolve 了一个 ( reject 的 promise )，所以 then 的结果会递归等待里面的 promise 返回，里面的 promise reject 了一个 42，碰到 reject 直接返回，被 then 的第二个参数抓到，所以得到了 “ reject 的 42 ”。
第三个和第四个 外层 promise 直接 reject 了一个 promise （不管这个 promise 具体是啥），所以直接返回，被 then 的第二个参数抓到，所以得到 “ reject 的 promise<xxx>”。
其中第三个因为内层 promise 是 resolve 的 42，所以结果是 “ reject 的 promise<resolve 42>”。
而第四个因为内层 promise 是 reject 的 42，外层 promise 被 then 的第二个参数抓住了，但内层的没有，所以结果是 “ reject 的 promise<reject 42> 并带有一个未捕获的来自内部 promise 的异常”。

不管你这个 promise 写多少层，resolve 都会递归下去，一旦碰到 reject 立即返回。

@renmu 只用检验位的话，只能确保这个身份证不是随便乱输入的，而仅仅是符合规则的……而最后一位只有 11 种可能，一下就试出来了……
并且检验通过的身份证号只是符合规则，无法判断是否与人名字关联，甚至是这个“身份证号”是否真实存在都无法判断！
比如身份证前 6 位为地区，中间 8 位填一个未来的日期，后面 3 位填个随机数，最后一位从 0123456789X 这 11 种可能中试（或者根据规则去算），这样就可以得到一个合法的假身份证号了！

cloudflare、google

youtube-dl 可以用，去他们 GitHub 仓库的 Release 下载最新版就行

考研教程看一边差不多了……网上有那种免费的视频……

G 强行翻译成 吉，就像 Windows 强行翻译成 视窗 一样尴尬……

@qq292382270 网页的协议新注册的微信号都不能用的，老微信号被检测到使用机器人也会封网页登录的。
所以基于 web 的自己玩玩就好，算作技术交流了，正式用还是风险太大……

windows 上用 nslookup 看一下 DNS ？
ipconfig /flushdns 清一下缓存，重启浏览器，或者干脆重启一下电脑试试？

你 dig 是 @127.0.0.1，浏览器却设置的 192.168.43.245 ，是这个原因吗？

过早优化不好，但顺手优化还是赞成的……
勿以优化小而不为，毕竟积少成多。随手养成良好的习惯，实现同样效果的代码，坚持使用最优的，即便是多写几个字母。
但说了是随手优化，所以没有必要为了写法的优劣而吵架！！！
但如果对一段代码的优化明显占用了工时，那就没必要了，这种优化还是放到最后需要优化的时候，测测瓶颈再来考虑是否继续吧……
关于框架，我觉得不能过于依赖。框架是用来加速开发的，如果同样的功能原生代码可以快速实现，没有必要专门用框架封装的。特别是大型框架，能够用来帮你组织项目结构，帮你组织整个工程的逻辑结构，这就足够了，其他封装的方法都只是“语法糖”。这些封装的方法有的为了适应不同的执行环境而写了大量的分支判断，这个时候，自己针对项目用原生代码实现一个量身定做的封装岂不更好？

试下 V2 是否支持 details

<details>
<summary>Just Test</summary>
Test...
</details>

googleapi 感觉是在做 GMS 推送之类的

我也觉得，如果单纯是语法糖的话，旧语法和新语法间可以完全相互转换的话，没有必要。

@shansing #28 看我的第二个回复，里面我指定了 Accept-Encoding 为 gzip 了，不包含 deflate，但服务器依旧以 deflate 进行回复，可见服务端是忽略这个头的……