@Clouder1 现在市面上看到的 QQ 、微信的 Linux 客户端，都是非腾讯官方开发的，无一例外，要么是封装的 web 版本，要么是用 wine 封装的 windows 版本。
web 版本随时有被封杀的可能（比如 web 版本的微信很多人就是不能登录的），并且 API 太少，体验不佳。
而 wine windows 的版本，体验稍微好一些，但是因为这些都是 32 位软件，需要 wine x86 的兼容层。现在的 Linux 大多都默认仅包含 64 位系统库了，可以单独装 32 位库，但会导致系统非常混乱。（这个可以参考 Steam for Linux 的 Github issue 仓库，因为 steam 不给 Linux 用户出 64 位客户端，导致安装 steam 必须装 32 位依赖库，而很多显卡驱动都不支持 32 位了，导致显卡驱动装不上。已经被骂了快 10 年了，骂到 Mac 和 windows 都有 64 位 steam 客户端了，Linux 还没有）
不过如果是系统预装 32 位库的话，到稍微好一些，QQ 微信 这些应该用不到显卡驱动，不过总归是有 wine 转换层，性能上还是比不过原生应用。

目前我的解决方案也是 wine，但是为了避免 32 位库污染我的系统，所以我是把 32 位 wine 装在 docker 里面用的，然后 x11 的 socket mount 进去。总的来说：能用，仅仅是能用。

@miku831 不是，是穿越去未来那一季，地球被炸了。

啊？难道不是一只狗吗？
https://blog.mozilla.org/firefox/the-fox-is-still-in-the-firefox-logo/nightly-doge-logo/

https://ffp4g1ylyit3jdyti1hqcvtb-wpengine.netdna-ssl.com/firefox/files/2021/02/nightly-doge-logo.png

浏览器不需要主页，甚至都不需要直接的入口，直接手机桌面带个搜索框（直接桌面带也行，桌面下拉出来也行），可以搜索、输网址、扫二维码，然后直接调出浏览器显示对应的内容就行了。

这个其实还有国内政策限制的，VoIP 网络电话在国内还是受限制的。微信这类语音软件为了避免 VoIP 政策风险，会故意弱化通话质量（在普遍可接受范围内）、阉割功能。比如 callkit 功能，直接让你手机上接听微信通话的时候，不使用消息推送通道，而是使用系统级更高优先级的通话界面来提示，就跟普通的电话一样了。（这个功能不是张小龙不做，是旧版微信支持、国外手机号注册的微信支持，新版微信、国内手机号注册的微信被强制删除）
如果你的微信账号不是在国内注册的，或者你微信绑定的手机号不是国内的，还可以解锁微信里的一个隐藏功能 wechat out，这个就可以直接拨打电话号码，不过就会收费了。

进 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 去掉应该就好了。