@fx777 泄漏的内存不会再次访问，没有换页操作，所以一般不卡。别的程序申请新的内存空间时会慢一点（取决于 SSD 写入性能）。

@liprais 也许是后来支持了，我已经有两年多没在 macOS 上用过了
现在已经卖掉了所有 macOS 设备

多用用就会发现
macOS 版本的 Firefox 甚至不能用触摸板手势缩放……

接 USB 设备不方便

泄漏的内存不会再被访问，内存压力可能都不会显示得很高，因为都不会产生缺页中断。
但这不意味着可以放任不管，哪怕不在乎 SSD 寿命和可用容量。
这个情况下，有程序想要申请更多的内存空间，物理内存已经被占满了而又不会回收，那么还得把泄漏的内存移到 swapfile 里之后才能申请。
那性能必然受到影响，有一些操作会感觉到比以往更慢。比如打开新的文件、PS 新建几个图层、DAW 软件加几个音轨这类操作。

这个问题只有大家都向苹果反馈才能从根源上解决，好多程序都会这样。

@zhaidoudou123 不会吧，各种 Linux 桌面都有这个功能……

@hfl1995 不用假如，我从 CRT 显示器时代就已经感受到这玩意伤眼了，而且比现在的 OLED 猛多了……
设置 60Hz 刷新率和 85Hz 刷新率都有很大差别，一个能看一小时，然后就得休息一下才行。另一个能看三小时。
后来用着 PWM 调光的 LCD 显示器，稍微好了一点，但也没办法看很久。
直到智能机普及之后我才第一次感受到 DC 调光的好处。
以上时间段里，我从未听说过任何关于 OLED PWM 调光伤眼的传闻，当年的 PSV1000 用 OLED 屏幕也是 DC 调光的。

@coolair 还真不太一样，这 iPhone 3GB 内存已经杀疯了
8G 内存的安卓除非厂商的省电策略太激进，其实还行。后台一般都可以挂 8 个，其中微信用了 1G 内存……
我有个红米 Note9Pro ，日常锁 3 个应用后台，没掉过。除了一些程序放后台自己崩溃没了以外(每次都能稳定被杀的)，平时使用没感觉到有程序被杀

看到楼上有人说没有替代品，给大家介绍两个不同用途的替代品：
1.Mark Text
官网： https://marktext.app/
源代码： https://github.com/marktext/marktext
这是一个所见即所得的 Markdown 编辑器，比 Typora 的功能更加强大，是以 MIT 许可协议开源的自由软件
支持 Windows 、Linux 、macOS

2.Joplin
官网： https://joplinapp.org/
源代码： https://github.com/laurent22/joplin
这是一个使用 Markdown 的笔记软件，也以 MIT 许可协议开源的自由软件，支持插件扩展功能。
可以设置定时同步到云端。云端存储除了官方的，也可以自建，或者使用 OneDrive 、DropBox 或者其他自建网盘服务，也可以同步到本地文件。能自由导入导出 Markdown 文件。如果感觉功能不够强大，也可以调用第三方 Markdown 编辑器进行编辑。
可以离线使用，支持密码保护笔记和端到端加密。支持所有主流平台，包括 Android 平板。

看到这个帖子才想起这个软件，已经好久没有安装过了

第一个问题是远古 bug 了，一直都有

@LinShiG0ng M1 Mac 小毛病挺多的，不光是兼容性的问题，用来干活各种糟心……
而 Windows 笔记本反而问题少很多，相比起来要更可靠一些。
M1 MBP 的优势完全没有办法抵消它的劣势，除非是用来开会一整天。

@LinShiG0ng 用 Windows 笔记本，我已经半年多没有用 macOS 了

4 年前做过这个，当时用 Windows + WSL1 + Hyper-V 跑 Docker
那时候的 WSL1 只需要配一个 export DOCKER_HOST=tcp://127.0.0.1:2375 环境变量
用 mount --bind 把 /mnt/c 挂载到 /c ，/mnt/d 挂载到 /d
之后就各种顺利了。chaincode 的编译，启动，调试过程也可以在 WSL 下进行，产生的文件也是 Linux 的可执行程序。

要是用 Linux ，只用来做开发的话就更顺利了，前期配环境也非常轻松。

要是用 ARM macOS 来做开发，我感觉跟 fabric peer / orderer 节点本身、以及 chaincode 相关的应该还是可以做的，只是需要做的工作有很多。
以前官方的开发环境是用 Vagrant + VirtualBox 来搭建的，这玩意还没兼容 M1 ，估计需要自己用 Docker 重新搭建一套，能够用来打出 ARM Linux Docker 镜像。
或者是尝试完全在 macOS 上运行，但不一定完全可行，这玩意极其依赖 Docker ，启动 chaincode 都要起一个容器，还得让 peer 节点用 unix socket 跟主机的 docker daemon 通信。

大坑可能在后头，比如它的 Node.js SDK 依赖了很多 C++ 库……

如果工作不是去建设 ARM Mac 生态的话，我觉得用新款 MBP 来做相关开发实在划不来。

若想要的是轻薄高性能长续航的笔记本，不妨考虑 Ryzen 5800U 处理器的轻薄本，或者是等 12 代酷睿？

@Perry 苹果能用 curl ，只可能会发生苹果给 curl 交保护费的情况，而不是反过来。
因为又不是 curl 开发者要求苹果内置它，并且 curl 也不依赖 macOS 设备带来的推广价值，而是苹果自己需要它。
让更多人能用上 curl 是一件好事，但开发者其实是没有依靠用户量来盈利的。这就决定了上述结论。
Google 作为商业公司，他想主动推广自己的产品，给 Apple 一笔钱来达成 Google 的目的而已。

@liprais 很多时候，开源的软件是没有售后的，往往都是“你行你上”那种。
提供售后的往往都是用来盈利的那一方，就像 RedHad 一样。

@Perry macOS 自带 curl ，作为系统的组件之一。系统上的程序都可以依赖 curl 来向用户提供功能。
而所有运行 macOS 的设备都是可以给苹果带来利润的。

> 那是不是以后员工用苹果电脑赚取巨额利润的公司都得给苹果交钱了？
先不讨论是不是应该交，但实际上都已经交钱了。

@liprais Apple 可以自己在下游提供补丁，更正 macOS 中附带的 curl 的文档，或者对 curl 做改进。
根据 curl 的许可协议，Apple 有权利不把改动反馈给上游。不需要参与 curl 的社区。
另外，苹果怎么就没有能力呢？
如果苹果向上游提交改进，估计作者都会把 Apple 添加到 THANKS 里面。

@Remember 苹果用了他的软件赚取巨额利润，而作者本人没有得到苹果的回报。在这个前提下，苹果来提供相关的服务和支持的显然是更合理的。
而苹果却只管用来赚钱，对于苹果平台特有的问题，也不想负责任，把一切都推脱给上游的开发者。
作者要强调的是好处都是你赚走，而责任你却一点都不想承担。