如果这个操作在短时间内做 1000 次，最后再把它改回原样，用 VDOM 就可以绕过所有重排和绘制工作
许多页面的生成过程，并不能像这个例子一样一步到位

自建梯子+MIUI13 大陆版本+MS Edge 浏览器
目前从未遇到过这个问题

@LotusChuan 我想到了一点，如果你看到一个进程的内存占用超过了系统的物理内存+交换的大小。那是因为还有“内存压缩”这一项，它算进了物理内存的大小里，而且是压缩之后的大小。
但进程的内存显示的是这部分数据解压缩之后的大小。

@LotusChuan 我没有找到“超过了物理内存和 swap 的总和”的那一项。未分配的内存本来就不应该列出来。
如果你是指 kernel_task 的“实际内存(Real Mem)”很大的话，那是因为虚拟内存本身就是建立在这上面的，当然会显得很大。
我并不觉得是“显示有问题，实际没有问题”。只不过我只能从其他现象推测出可能存在内存泄漏问题，而不能向你保证它一定是这个问题。

@LotusChuan 苹果确实没有什么文档来描述“内存”这一列数值的实际含义，不过，把整个页表的地址范围都显示出来并没有什么实际意义。从用户的角度来讲，用户看到这个数值，点一下排序，就可以知道什么程序占用了比较多的内存。结合用户的需求，就可以知晓，关掉哪个程序能够尽可能地腾出内存空间。

苹果倒是有一篇文章讲了内存系统的设计，但并没有说明“活动监视器”中“内存”这一列的含义。
https://developer.apple.com/library/archive/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html

这些程序确实是个黑盒，然后还没有相关的资料。但这反而让人感觉更不靠谱了。若你开发的软件真的存在内存泄漏的问题，也许你都没办法意识到这个问题存在。

然而几年前的 macOS 虽然长时间不重启也会出现一些小毛病，但各种系统进程的内存使用量数值也没有像现在一样夸张。我不敢保证它一定有某种问题，但我不觉得它没什么问题。

我只想说从“不卡，不影响使用”的角度来证明它没问题，其实不靠谱。真正的内存泄漏，在使用固态硬盘的情况下，还真的可能感觉不到“卡”。

那种卡顿感更多是机械硬盘带来的，Windows Vista 之后的 Windows 都有一项叫做“Ready Boost”技术，宣传你可以使用一个 U 盘（并没有多高的性能要求，只需要 USB 2.0 ，如今听起来已经有点离谱了）来提升电脑性能。因为 U 盘的随机读写性能好过机械硬盘。
当你的电脑有 SSD 的时候，这个功能的界面上就会显示，你的电脑已经不需要它了。

@LotusChuan
1. 那些缓冲加速用的进程，在设计上就给了很低的重要性，内存不足的时候首先会把它们杀掉；
2. 系统内核里哪里有虚表的概念，那是 C++之类的语言为了实现多态而引入的设计。程序可以向系统申请一定大小的内存，可以是私有的，也可以是共享的（例如多个程序使用了同一个动态链接库）。如果没有 swapfile 这种设计，内存不足时其他程序当然就申请不到内存了。

当然我知道你想说的第二点是什么，其实这对应 Windows 的“提交大小”。也就是程序向系统申请的内存大小，而不是放在物理内存中的那部分大小。
但排查有没有发生内存泄漏的时候当然就是关注这个指标（即程序向系统申请的内存大小，而不是实际使用的），毕竟物理内存可能只有 8GB ，但程序却申请了 10GB ，其中一大半在 swapfile 里面。你去查看程序使用的物理内存大小，那永远不可能超过 8GB 。
这时候还要骗自己“它占的物理内存没有增加，所以没有内存泄漏”吗？

内存不足的时候，泄漏的这部分内存页面根据最近最少使用机制，当然优先被放进 swapfile 了。而且因为内存泄漏之后，程序逻辑里没办法访问它们，所以它们也没有机会再被放进物理内存中。

硬盘上多了一段永远不会用到的数据，大多数时候当然不会让系统变卡。当然，新程序启动的时候，或者程序打开一些文件的时候，系统把物理内存中的数据（也包括泄漏的部分）写到硬盘里，这时候会比以往要慢一些。

但因为大多数时候启动一个程序或者打开一个比较大的文件都得花上不少时间，稍微多个一两百毫秒，用起来根本没什么感觉。所以并不能根据“内存用了这么多还不卡”的主观感受来判断是不是内存泄露。

至于我有没有证据证明内存没有回收，你可以关注一下硬盘可用空间的大小，硬盘的写入量统计信息，以及为什么这个论坛里不少用户一星期要重启一次电脑。当然也有人不信，觉得 smartctl 的数据是假的。那就没有什么办法了。

@LotusChuan 一方面是做这些事情根本用不着如此多的内存，另一方面是内存不足的情况下它也不能收缩，根本不在程序控制范围内……

@LotusChuan 回收不了，当然是

@LotusChuan 占了也不一定在用，有时候多占点反而快：这说明是内存泄漏了，泄漏的内存程序没法访问到，放进 swap 里都只是单纯地占据硬盘空间，永远不会再次调回内存。

@quzard 4 扬声器其实只是能保证每一个方向的声音都是立体声
iPad Pro 的扬声器虽然也是 4 个，但是实际上每个扬声器有两个单元，做了分频
扬声器的体积也大一些，调音（软件均衡器实现的）也好一些

@quzard 如果预算在 2000 多，看剧用安卓平板反而还不错。4000 以上的话，iPad 有外放音质的优势和屏幕优势。

AutoHotKey
一个用脚本来实现自动按键的软件，和按键精灵相似。
可以用来将一些固定操作做成快捷键，也可以用来实现复杂的改键逻辑。

一个在 AHK 的基础上开发的 Windows 虚拟桌面快速切换、将窗口快速移动到指定桌面的工具：
https://github.com/pmb6tz/windows-desktop-switcher

在 Windows 11 上似乎有些小毛病，Windows 10 用起来效果挺好。

@droppedbytech 其实我也不太确定一些细节对不对，因为没有看过内核源码……

@wuqiangroy 其实已经出现因为内存不足而影响性能的情况了
苹果的文档： https://support.apple.com/zh-cn/guide/activity-monitor/actmntr1004/mac

截图的数据解读如下：
整台电脑一共有 8GB 的物理内存
被使用的部分为：
作为支持程序运行的部分：7.01 GB
作为缓存，以提升程序或者文件的访问速度的部分：956.4 MB ÷ 1024 = 0.93 GB
实际剩余的物理内存大小：8 - 7.01 - 0.93 = 0.06 GB

在 7.01GB 的数据中，有 3.37GB 是不能直接访问的，而是被压缩的。
内存压缩是什么：由于在 SSD 上使用交换文件的性能比较低，因此，可以在内存上开辟交换空间来提升系统的响应速度。数据存储进去之前需要进行压缩，读取之前需要解压缩，并放在苹果所说的“App 内存”区域，才能被程序使用。
这样做可以在比较小的内存下获得比较不错的性能。Windows 和 Linux 都支持这样的技术。

对于大多数程序和文本数据，可以压缩到原本的 1/3 大小，因此，其中包含的内存数据解压缩之后约有 3.37 × 3 = 10.11GB 。

如果你有用过内存超级大的 Mac 机，会发现“被压缩”部分的内存很少，甚至是 0 。因为内存负载还没有达到换页的阈值，系统只会直接使用物理内存。压缩和解压需要消耗 CPU 资源。

剩下 7.01 - 3.37 = 3.64 GB 可供系统和应用程序使用
其中包含了被苹果称为“联动内存”的数据，有 1.57 GB ，即“无论如何都无法放到交换中，只能保留在物理内存里的数据”。一般都是系统的核心进程数据，显存，或者硬件虚拟化使用的内存空间。
注：上面所述的交换包含两部分，一部分在硬盘文件里，另一部分压缩后保存在内存上。“联动内存”无法被换页到这些地方。

最后真正能被程序使用的部分，只有物理内存上面的 1.54 GB 那么大。
而且实际上这部分空间已经不能再增长了，如果想增长，有两个方法：
1. 放弃文件缓存，这可能会导致非常糟糕的硬盘 IO 性能，使系统卡顿更加严重。
2. 把“被压缩”部分展开到 10.11GB ，并且写到交换文件里。这样就腾出了 3.37 GB 可供使用。这会使得系统发生缺页中断时，换页的效率更低，因为从 SSD 中读写数据比在内存中压缩 /解压缩要慢。
对于第 2 点，若腾出的内存空间不足以减少换页的频率，同样会使得系统卡顿更加严重。

有两种情况：
1. 如果程序要访问的内存在很长一段时间里都比较固定，并且大小只有 4GB 左右，这么做就有正面的影响。
2. 如果各种程序都频繁访问交换中的任意内存数据，那么保持现状才能获得较好的性能。

macOS 提供了一个指标来更好地衡量目前的换页情况，即“内存压力”。当系统的内存不足并且又频繁发生缺页中断时，“内存压力”的数值就会上升。在截图里，“内存压力”的数值已经超过了一半以上，说明目前各种程序都在频繁地访问交换中不同区域的内存数据。因此对应情况 2 。

由于内存过小，已经影响了系统性能。

根据这张图，也可以估算出多大的内存才能完全不影响系统性能。
目前物理内存中没有被压缩的数据占据了 1.54 + 1.57 + 0.93 = 4.04 GB
压缩的部分要计算解压缩后的大小，即 3.37 × 3 = 10.11 GB
硬盘中有 1.48GB 的交换文件
所以实际内存需求一共有 4.04 + 10.11 + 1.48 = 15.63 GB

只要 16 GB 的内存就可以满足当前的使用场景，而不会感受到因内存导致的性能问题。当然，无法解决因为软件 bug 导致的卡顿。

@xooass M1 刚发布的时候确实有很多帖子中有不少用户在说“8GB 等效于 16GB”。当然，也有人指出了问题，得到的回复大多是“不卡就行，没必要关心这么多，macOS/M1 的机制不一样”。

随后就冒出不少抱怨“SSD 写入量过大”的帖子了。
再往后才是“8GB 不够用”的时代……