今早微信开发者工具启动慢，项目加载慢，预览也慢。机器是 Apple M4 Pro，14 核，24GB 内存，原装固态，macOS 15.6，磁盘还剩 463GB。这种配置对不上「电脑太旧」的解释。
下面是同一次会话里量到的数。工具是稳定版 2.02.2609240，Electron 36.6.0。打开的是一个 12 个源文件的小程序示例。
一次启动实际花了多久
进程 09:07:36 拉起。
| 时刻 | 距启动 | 发生了什么 |
|---|---|---|
| 09:07:48 | 12 秒 | 自动打开上次的项目 |
| 09:08:10 | 34 秒 | 项目窗口起来 |
| 09:08:35 | 59 秒 | 编译子进程才创建 |
| 09:08:43 | 67 秒 | 12 个源文件解析完，整批 355 毫秒，最慢单文件 71 毫秒 |
| 09:09:39 → 09:09:56 | 约 2 分钟 | 第一次模拟器编译，这一段单独 16.5 秒 |
| 09:10:22 → 09:10:23 | — | 第二次模拟器编译 0.4 秒 |
| 09:10:33 | 3 分钟 | 编辑器扩展宿主才启动 |
| 09:10:43 | — | 首页启动超时，已经等了 12.8 秒 |
预览走的是上传链路，整段 37.1 秒：本地编译 16.2 秒，打包 5.6 秒，传到微信对象存储再等 12.7 秒。前一天同页也有一次首页启动超时，等了 10 秒。
源文件解析是几百毫秒。热的第二次模拟器编译是 0.4 秒。慢的是冷启动、第一次把模拟器拉起来，以及预览时的整包编译和上传。
安装包是 Intel 的
主程序是纯 x86_64。系统对这个进程的标记是 X86-64 (translated)，内存里有 Rosetta 的即时翻译区。编译器、模拟器、编辑器都在这层转译上跑。
同一时刻，主进程大约 220MB 可写内存已经被换出。程序在算的时候，还要先从磁盘把页调回来。
24GB 当时是满的
采样时机器已经开机两天。真正空闲的物理内存大约 117MB。活动和不活动列表大约 11.4GB，内核锁定大约 4.0GB，压缩器大约 8.0GB，加起来就是 24GB。压缩器里压着大约 35GB 逻辑内存。14GB 交换分区用了 12.8GB，这两天累计往磁盘换出过大约 31GB。
当时驻留最多的是这些：
| 应用 | 驻留内存 | 进程数 |
|---|---|---|
| Cursor | 4.3GB | 67 |
| Chrome | 3.2GB | 49 |
| 微信 | 0.6GB | 14 |
| Codex | 0.6GB | 19 |
| Spotlight | 0.5GB | 19 |
| 虚拟机 | 0.5GB | 1 |
| DeepSeek Harness | 0.5GB | 8 |
| Docker | 0.4GB | 15 |
微信开发者工具自己大约 1.5GB、27 个进程。它退出之后，Cursor 和 Chrome 仍占着大约 7.5GB。
活动监视器里的内存压力，来自工作集大于 24GB。放不下的部分被压缩，再被换到磁盘。没有单独一个进程占掉几十 GB。
Cursor 的 4.3GB 怎么来的
Cursor 开着 7 个窗口。每个窗口是一个独立的界面渲染进程，七个加起来大约 2.4GB，从 184MB 到 619MB 不等。最大的那个，一般是长对话或大文件一直留在界面里。
每个窗口还会再起一个扩展宿主，把已启用的扩展再加载一遍。当时有 11 个扩展宿主，合计大约 1GB。其中一个窗口额外挂了检索、本地索引、Agent 执行三个宿主。主进程另有大约 217MB，这是打开 Cursor 的固定成本。
Chrome 的 3.2GB 怎么来的
Chrome 156 按站点拆进程。41 个渲染进程合计 2.6GB，中位数大约 48MB，只有一个到了 263MB。浏览器主进程 375MB。默认配置里 6 个扩展，扩展进程合计大约 120MB。
Chrome 这边是标签页和内嵌页面多，每个站点一份大约 50MB 的底。
项目和缓存对不上这个量级
示例项目一共 279MB，其中 node_modules 278MB，打包配置已经忽略它。工具自己的数据目录 349MB。源文件解析只要几百毫秒。清缓存对不上启动那 3 分钟，也对不上预览那 16 秒本地编译。
启动日志里还有两处小问题：读用户信息超时，以及两个基础库更新时连接被重置。它们是秒级的。
预览编译开着 ES6、增强编译、代码压缩和上传 source map。对 12 个文件，这些开关会加工作量，量级仍然落在转译和换页上。
以后怎么用
- 微信开发者工具换官方的 macOS Apple 芯片版。启动、模拟器冷编译、预览里那 16 秒本地编译，都在 Rosetta 这一层上。这次还没有换上再测一轮，所以快多少要等下一次同样的计时。
- 这种负载下，两天不重启就会把交换分区写满。用开发者工具之前，先退出不看的 Chrome 标签、不用的 Cursor 窗口、Codex、DeepSeek、Docker 和虚拟机。重启也能把压缩内存和交换分区清掉。
- Cursor 同时只留正在改的窗口。7 个窗口是大约 3.4GB 的固定成本。一个窗口涨到五六百 MB，新开对话，旧上下文不必一直留在界面里。Agents 窗口不用就关。扩展只留真正在用的，每多一个，每个窗口的宿主都会再涨一截。
- Chrome 用自带任务管理器看那个两百多 MB 的标签，用完就关。打开内存节省模式。常驻标签控制在十个左右，启动时不要恢复上次的全部会话。
- 预览的 37 秒里，大约 13 秒是上传到微信服务器。换芯片版消不掉这一段。本地的 16 秒编译和 6 秒打包才会下来。
先看进程是不是原生架构，再看整机还有没有空闲物理内存。这两项对得上之后，才值得去看项目体积和缓存。