我平时用 MacOS 和 Win10，会做 Web 全栈开发，对我来说：

续航：Mac ；
触控板：Mac ；
开发依赖的 Linux 环境：Windows （ WSL ）；
窗口管理：Windows ；
Docker：都不好用，换虚拟机+docker-machine 方案。

MacOS 是基于 BSD 的，不是 Linux，在 Linux 发行版上的使用体验可能会在 BSD 上变得糟糕，MacOS 在 POSIX 偏好和指令工具的选择上都跟主流 Linux 发行版有很多区别，想以 Linux 的习惯畅快使用的话，得折腾一下。
这方面 WSL 更有优势。
WSL+Windows 版 XServer 可以跑 GUI 程序，比如 IntelliJ 。

这俩没有绝对好坏，主要看使用习惯，其次看你的实际需求。
另外现在芯片都足够强大了，你的应用场景要求的计算量又不大，没必要迷信苹果芯片。

你觉得你身边打 ACM 的就只会刷点简单的 ACM 题，那么那些打 ACM 的人可能也觉得你就只是了解一些时下流行的工具而已。

打竞赛不是玩游戏，有问题大家讨论问题，没有任何必要唱反调，因为你不能假设每一个讨论的人是什么样的知识和技能水平，假如你是一个计算机技术很好的人，在发帖讨论某道 ACM 题的各种思路，然后有人上来就让你去了解计算机基础，你肯定会觉得莫名其妙。

做竞赛、做工程、做研究是三个不同的方向，不存在哪一个方向做得好了其他方向都能做得好。

一项工作越复杂，就越可能同时需要多个方向的人才；每个人都可以选择自己的发育路线，打好自己的位置就行，管别人也没啥意义。

作为一个技术人员，技术到了一定程度之后，发展瓶颈就成了知识和技能的广度，要想继续发展，就需要在其他方向加点了。
将来参加工作之后，特别是参加工作两三年之后，不管是哪个方向出身，大家都会去补课，计算机基础差的回去补基础，算法差的会去补算法，也有的人会作为选手参加竞赛的集训（比如地区或单位的代表队）。

当一个人对一个事物不了解的时候，这个人会倾向于使用自己过往对其他事物的经验来给眼前这个事物下定义，但当这个人了解的知识越来越多，就会不断打破自己以前下的定义，无限趋近于事物本质。对于打竞赛，你没有真正参与过的话，不做评价是最明智的。

结婚对象要求彩礼：有能力就给，没能力就换人。
家属要彩礼：民政局给你们发证是不会征求家属意见的。

结婚最起码价值观的一样，否则彩礼只是个开头，后面还有大半辈子。

北京确实车辆跟行人抢道，今早刚遇到过一次，问题最大的是红灯右转。

公交司机礼让的多，但其他大巴司机很多都急脾气。

推荐个好用的东西，叫冰球壶，密封，而且灌水和取冰都挺方便的。

Debian 、Ubuntu LTS 、OpenSUSE 都可以，或者花钱买 RedHat 。

结尾米莉和键盘那一段有点冗赘了，其实可以理解，前面整部都做了各种铺垫，指向键盘对米莉的感情，如果结尾不来这么一段就感觉前面白铺垫了，但这个结尾又加得有点突然。

其实盖和巴迪相拥离开的那一幕直接结束就很完美了，米莉和键盘的后续可以放在演员表之后的彩蛋里……

其实一个人活得好不好，还是得问这个人自己，其他人的评判没有意义，自己的路自己选择，只要走下去就有意义。

如果不考虑 try/catch 的话，两种写法就是一样的，promise 有个特性可以确保 resolve 返回的不是个 promise，而是层层 resolve 之后的值，比如主题里的第二个不加 await 的写法在外部调用 await fun()之后不至于返回的是个 promise 。

@autoxbc #16 想点进去看看高赞是什么，竟然是我写的……

洗，然后烘干或晒干。

保存衣物可以用压缩袋，隔绝湿气。

不同模型的数据，用不同的数据库。

当需要存储一个层级很多的树状结构的时候，关系型数据库需要给每一层都创建一张表，然后表之间建立联系，查询的时候也要在所有表中进行查询。
用文档型数据库只需要一个集合，查询也只需要一条原子语句查这个集合。

当需要存储一个 N 对 N 关系的结构的时候，实体之间是纯关系模型，此时用文档型数据库就必须为每种实体建立一个集合，然后集合之间互相引用，查询也只能递归查询。
用关系型数据库就方便很多。

另外 ES 不是数据库，ES 是不保证一致性的，本身有刷新周期，在两个刷新周期之间做的任何写操作，都不能读出最新结果，必须等到下一次刷新后，才可以。
设想一个查询表单有二十个查询参数，每次查询都会在这二十个查询参数中随机选取随机数量的参数组合作为查询条件；这种需求用传统业务数据库难以做到高性能查询，受限于索引的机制，理论上要达到稳定的高速读性能要将这二十个参数的全组合都创建为索引，但对于传统业务数据库来说，索引越多就意味着写性能越差。ES 就是专门应付这种场景的，所以为了兼顾一致性和查询性能，很多系统会用业务数据库+ES 将数据冗余两份，业务数据库负责写操作和一致性读操作，ES 负责非一致性读操作，两边做好同步。

MongoDB 从 4.0 就支持事务了，现在很多人对 MongoDB 有偏见是来源于很多年前对与 MongoDB 的了解。

没有任何一种技术能满足所有需求的，所以我们才会需要各种数据库、中间件来配合实现需求。

一时间不知道怎么回复……

关于内存泄漏：

要用内存的时候需要申请，用完了要释放，这些操作仅存在于可以直接操作内存的语言，如 C 、C++，申请了内存忘了释放会导致内存泄漏，在一些重业务轻资源管理的场景下，人们发明了一些自动释放内存的语言，如 Java 、C#、JS 、Go，大多是采用 GC 方案，也有采用其他方案的如 Rust 的 safe 的代码采用 Ownership 方案。

但不是说有了自动释放内存的方案就可以完全避免“内存泄漏”了，没有遵照 GC 、Ownership 的规则来使用同样会导致内存泄漏，比如持续创建对象，但又让对象持续被引用，GC 检测到对象被引用则不释放内存，可能业务上已经用不到这些对象了，但对象依然越来越多，直到用满内存。

所以对于 JS 来说，绝大多数时候都不需要考虑内存相关的问题，特殊情况下要释放内存也不需要借助析构函数之类的特性，而是随时都可以直接为 GC 创造条件诱导其释放内存，比如打破引用关系，比如使用 WakeMap 。

关于析构函数：

C 语言也没有析构函数（非 OO 连构造函数都没有）。
析构函数（ destructor ）是面向对象编程思想里的一个概念，存在于 RAII 方式的场景，RAII 方式的特点是资源的分配和释放的时机是被精准控制的。JS 是使用 GC 来释放内存，GC 的释放时机是不确定的，而且假如对象不满足 GC 释放要求的时候强行释放可能会导致有些资源被提前释放了，从而使得引用关系树紊乱，这也是 GC 要避免的问题之一。你可以使用 FinalizationRegistry 来监听对象被 GC 回收的事件，某种意义上来说可以算是一种“析构函数”，但这个与其他很多语言的方式有很大区别，开发者无法预料这个事件什么时候发生，但如果契合你的需求场景，也是可以用的。同时不同 JS 引擎对于 GC 的实现也可能有差异，过度关心内存可能会导致程序兼容性下降，特别是适配问题很烦人的浏览器端开发场景。

关于释放文件句柄、网络连接、锁：

这些资源跟内存是完全不同的，确实是需要手动释放的，但不是说必须用析构函数，C 语言没有析构函数，除了要手动释放内存以外，也要释放这些非内存资源。
JS 也一样，相关 API 也都提供了诸如 filehandle.close()、writableStream.end()之类的方法，但并不一定需要在对象被回收的时候释放。用 C++之类的语言的时候，有析构函数可以用来释放内存，于是当其他资源生命周期和对象一样的时候，可以一起放在析构函数里释放；但并不是说释放资源一定要在析构函数里做，C++也可以不在析构函数里释放这些资源。人们在用 JS 的时候，压根不会去考虑内存释放的问题，所以也压根不会考虑使用析构函数，那么只要是符合业务流程定义的位置，都可以显式调用方法释放相应的资源，你可以直接在一个代码流程中释放，也可以监听相应事件来释放。
如果程序中没有释放资源，当进程退出的时候（ Node.js 支持多进程编程），操作系统也会回收所有资源，包括内存、文件句柄、网络连接等等。

最后：
1. 不知道题主是否明确清楚自己是否真的需要析构函数来释放这些资源，如果只是从 C++之类的开发精力带过来的习惯，那大可不必，JS 和其他语言有很多不同点，很多时候在一个语言上硬套另一个语言的思路会步履维艰，最终会觉得这个语言很难用。不如拥抱这个语言自己的开发习惯，可以参照一些主流项目的代码，看看大家一般会怎么做。
2. 语言表达的最终目标是让别人准确理解自己的意思，所以使用概念的时候还是要多加斟酌的，看是不是自己想表达的那个意思，造成误解可能会有其他连带的麻烦。

同一行业出现了不同的玩法，自己不加入的话，也就无法跟别人竞争，万一别人玩通了，自己再追就很难了。

所以这应该算是正常、合理的商业决策结果，不寒碜。

不过也确实能看出，Intel 不像以前那么自大了。

@libook #67 额网址后面忘了加空格了，导致和后面的文字连一起了，自己复制粘贴再访问吧。

另外想在 MacOS 上用 GNU 的指令的可以用 Homebrew 装相关的指令 brew install coreutils findutils gnu-tar gnu-sed gawk gnutls gnu-indent gnu-getopt grep

另外 brew search gnu 也可以搜到其他的 GNU 指令包。

装完后需要把指令路径加到 PATH 的左侧，可以参考我这个 zshrc 的脚本片段： https://github.com/libook/IdleBox/blob/master/zshrcs/public/config-gnu-commands

苹果电脑的优势在于硬件和系统都是苹果自家做的，所以可以做各种优化，长续航和性能很大程度上都在于系统和硬件的完美适配。

这个思路套到 Linux 笔记本上，你得找有 Linux 发行版专门做过优化的型号，比如 System76 就是专门做 Linux 笔记本的，他们自己做的 Pop!_OS 发行版会对他们自己的笔记本硬件做适配，但我没用过，所以也不知道效果怎样。

另外就是一些品牌如 XPS 和 ThinkPad 会出开发者版的型号，预装 Linux 发行版的，但貌似只在海外市场有，买的话估计要海淘。

最不济的方案就是用 Linux 发行版认证过的的硬件，比如 Ubuntu 的 https://ubuntu.com/certified，这个可以保障特定版本的系统在某些型号的笔记本上可以正常运行，但不一定保证做了优化。

要想在 MacOS 上有 Linux 环境的体验，也挺折腾的，比如 MacOS 的指令都是 BSD 生态的，你跑个 Linux 脚本可能会出现 sed 报错的问题，这是因为 BSD 的 sed 和 GNU 的 sed 参数很不一样。
如果希望使用 Linux Kernel 的一些特性的话，MacOS 也完全满足不了需求，举个简单的例子就是 Docker，Windows 和 MacOS 下只提供了封闭的 Docker Desktop，夹带了大量商业私货，性能差而且还有很多 Bug，还不支持完整的 Docker 特性，忍无可忍之后我转而用 VirtualBox 或 Hyper-V 来使用 docker-machine 方案，但你在 Linux 系统中这些障碍都不存在。

Linux 发行版一大堆，极少有人尝试过所有主流发行版，桌面这方面也是发行版维护团队做适配的，只要适配做得好，也可以很好用。

Linux 生态灵活性很高，对于牛人来说完全可以打造出符合自己要求的使用体验，但对于不愿意学习和折腾的人来说，还是老老实实用商业支持的产品吧。

请专业的杀虫公司来处理一下吧，如果少量蟑螂自己按照说明投药还有点效果，但这么严重的情况还是得先找巢穴再规划怎么投药。

我亲戚就是遇到过一次很严重的情况，然后请专业公司来搞效果很明显。

不过这个是个需要定期做的事情，另外也得想想办法封堵外面进入，以及搞好卫生。

Linux 操作系统会尽可能把内存利用起来作为 cache，所以你只需要对文件进行读操作，操作系统就会在内存里把文件内容缓存下来，只不过实际内核和应用程序需要使用内存的时候，再释放一部分缓存来给内核或应用程序。

你可以用 free 指令看一下，看有多少 cache 。

非要用应用程序把内存用满的话，你可以试试玩 Minecraft 的高清材质，我一年前用 OptiFine 的时候用某 1024 高清材质包会用掉 20G 的内存，据说同一材质的 2K 版本需要至少 48G 内存。

Querystring 的规范是在 RFC 3986 https://datatracker.ietf.org/doc/html/rfc3986#section-3.4
以及 WHATWG 的规范 https://url.spec.whatwg.org/#concept-url-query
可以看出来，querystring 仅仅是一段 string 而已，RFC 里规定了这个 string 从什么地方开始，到什么地方结束，可以和不可以包含哪些字符，并未规定 querystring 内实际的格式是怎样的。

所以这个是取决于前后端约定的。

但是这种通过 URL 传键值对的需求非常多，所以 HTML5 的制定者，WHATWG 在 URL 规范中直接说明可以用 application/x-www-form-urlencoded 的格式来传递键值对，算是把行业约定固定下来了（还顺便吐槽了一下这个方案比较坑）： https://url.spec.whatwg.org/#urlencoded-parsing
大概意思是没有=的话，就当成 name 。

恩，这就是答案了。

WHATWG 又贴心地提供了一个轮子，叫做 URLSearchParams，基于 application/x-www-form-urlencoded 格式进行封装，任何实现了 HTML5 的浏览器都提供了这个 API，而且和 URL API 有联动，后端像 Node.js 也在标准库里将这两个 API 收录，可以直接用了。