# 16GB Mac 同时开 3 个 Cursor 拯救我的 mac

> 16GB MBA 同时跟三个项目、三个 Cursor 窗口，写着写着就卡到鼠标抖。记录我把内存压回去的几个改动：关闭哪些扩展、调哪些 setting、什么时候该走"一个项目一个 workspace"，以及最后通过哪几条规则给自己定了"Cursor 用量上限"。

- URL: https://tenggouwa.com/posts/16gb-mac-3-cursors/
- 发布: 2026-05-06
- 标签: Tool, mac, curosr

# 16GB Mac 同时开 3 个 Cursor 拯救我的mac

## 起因:三个 Cursor 窗口把我的 MBA 干瘫了

最近一段时间在公司同时跟三个项目:一个是 Next.js 的 mono-repo,另外两个是相对独立的业务项目。我习惯每个项目开一个 Cursor 窗口,这样切起来直接 Cmd+Tab 就能跳。

直到有一天,我的 MacBook Air 16GB 开始**频繁卡顿**——切窗口要等一两秒,滚代码会顿,Cmd+P 搜文件输入半天才有反应。打开活动监视器一看,人傻了:

| 指标    | 数值       |
| ----- | -------- |
| 已使用内存 | 13.92 GB |
| 已压缩内存 | 6.86 GB  |
| Swap  | 3.88 GB  |
| 内存压力图 | 几乎全黄     |

16 GB 物理内存被吃干,系统在拼命压缩、换页。**这卡的根本不是 CPU,是内存换页造成的 I/O 等待**——这种卡顿比 CPU 满载还让人难受,因为它无规律,你不知道下一次点击会卡多久。

不能换电脑(短期),又不想关项目(影响工作),只能想办法治。下面是我花了大半天折腾出来的全过程,**最终把内存压到 11.97 GB,内存压力曲线全绿**,记录一下,免得自己以后忘了。

* * *

## 第一步:搞清楚谁在吃内存

把 Cursor 相关的进程拎出来:

```
WindowServer                                         1.22 GB
Cursor Helper (Plugin) extension-host (user) 项目A   1001 MB
Cursor Helper (Renderer) ×3                       共 1.91 GB
Cursor Helper (Plugin) extension-host (user) 项目B    530 MB
Cursor Helper (Plugin) extension-host (user) 项目C    479 MB
Cursor Helper (Plugin) extension-host (always-local) ×3  共 ~640 MB
Cursor Helper (Plugin) extension-host (agent-exec) ×3    共 ~640 MB
Cursor Helper (Plugin) extension-host (retrieval) ×2     共 ~430 MB
tsserver                                              421 MB
```

光 Cursor 全家桶就 5.5GB+。叠加微信、钉钉、Arc、iTerm2、Claude Desktop、Insomnia 这些常驻应用,16GB 不够用是必然的。

但这堆进程到底都是干嘛的?这里得先建立心智模型,不然后面优化时根本不知道在关什么。

* * *

## Cursor 的进程结构(Electron 多进程模型)

Cursor 是基于 Electron 的,本质上是一个套壳的 Chromium。它的进程结构是这样的:

```
Cursor 主进程
├── Renderer 进程       ← 每开一个窗口一个,跑 UI(~500-600 MB)
├── Extension Host 进程
│   ├── (user)          ← 你装的扩展(Claude Code 在这)
│   ├── (retrieval)     ← Cursor codebase 索引
│   ├── (always-local)  ← Cursor Tab 等本地 AI
│   └── (agent-exec)    ← Cursor Agent
├── GPU 进程
└── 其他共享 helper
```

**关键的认知:每开一个 Cursor 窗口,就多一整套这些进程**。这就是为什么我开了三个项目,内存呈线性爆炸——每一项都乘以 3。

我日常的工作流是 Cursor + Claude Code 插件,不用 Cursor 自带的 AI(Tab、Composer、Chat 都不用)。所以 retrieval、always-local、agent-exec 对我来说**全是浪费**——它们在烧内存做我用不到的事。

那能不能关掉?往下试。

* * *

## 第一刀:关掉 Codebase Indexing

Cursor 的 Codebase Indexing 是给它自己的 AI(`@codebase`、Composer 那些)用的——把整个仓库的代码切片、生成 embedding、上传云端。

我担心的事:**关了会不会影响日常开发?**

研究了一下,发现 Cursor 这个索引**只**给 Cursor AI 用,跟下面这些一点关系都没有:

| 你用的功能           | 背后         | 受影响吗 |
| --------------- | ---------- | ---- |
| 跳转定义 / 自动补全     | tsserver   | ❌    |
| Cmd+P 搜文件       | VS Code 内置 | ❌    |
| Cmd+Shift+F 全文搜 | ripgrep    | ❌    |
| Claude Code 读代码 | 它自己的工具     | ❌    |

放心关。操作路径:`Cursor Settings → Indexing & Docs`

要做三件事:

1.  **每个项目分别 Delete Index**——切到对应窗口才能删,不是全局操作
1.  **关闭 Index New Folders**——以后新项目不再自动索引
1.  **关闭 Index Repositories for Instant Grep (BETA)** ——这个跟 codebase 共享 retrieval 进程,只关一个不会让进程消失

> ⚠️ 我第一次只关了第三个,以为大功告成,看活动监视器 retrieval 进程还在 200MB+ 躺着。后来才发现这俩共享进程,**两个都关掉 retrieval 才会消失**。

做完这一步,**retrieval 进程清零,省下约 600 MB**。

* * *

## 第二刀:Tab 和 Agents 设置清理

按同样的逻辑,我把 Cursor 设置里所有跟 AI 相关的开关都过了一遍。

**Tab 菜单**:Cursor 自带的 AI 补全,不用——所有开关全关。

**Agents 菜单**:

-   `Max Tab Count` → 改成 1(不用 Cursor Chat)
-   `Commit Attribution` / `PR Attribution` → 关(谁要看"Made with Cursor"这种东西)
-   `Inline Diffs` / `Jump to Next Diff on Accept` → 关
-   `Toolbar on Selection` → 关(选中代码时弹的"Add to Chat"工具条,纯打扰)
-   `Web Search Tool` / `Web Fetch Tool` → 关
-   `External-File Protection` → **保持开启**(安全保险,虽然你不用 Agent,但万一误触有保护)

兴致勃勃改完,重启 Cursor 一看活动监视器——

**always-local 和 agent-exec 进程还在!**

研究了半天才搞明白,**这俩进程是 Cursor 启动时作为核心扩展宿主加载的,不是某个具体功能开了才起**。这些设置只是控制"行为"(什么时候自动运行、是否显示),不是控制"是否加载"。

也就是说,**这一档优化几乎没省到内存**。它的意义只在于关掉用不上的 UI 元素,让界面更清爽。

> 这是这次治理踩的最大的认知坑——**Cursor 的设置开关分两种:行为开关 ≠ 加载开关**,大部分都是前者。

* * *

## 大招:Multi-root Workspace

到这里我开始反思:折腾半天,设置层能省的有限。问题的根源是**三个独立窗口意味着三套进程**——能不能让它们共享?

答案是 **Multi-root Workspace**——VS Code/Cursor 内置的功能,把多个项目合并到**同一个窗口**里。这样三个项目共享:

-   1 个 Renderer(原本 3 个)
-   1 套 extension-host(原本 3 套)

操作很简单:

1.  打开任意一个项目窗口
1.  `File → Add Folder to Workspace...` 把另外两个项目加进来
1.  `File → Save Workspace As...` 保存成 `.code-workspace` 文件

我的 workspace 文件大概长这样:

```
{
  "folders": [
    { "name": "🏠 main-project", "path": "/path/to/main-project" },
    { "name": "🔧 service-a",     "path": "/path/to/service-a" },
    { "name": "🐾 tool-b",        "path": "/path/to/tool-b" }
  ],
  "settings": {
    "files.watcherExclude": {
      "**/node_modules/**": true,
      "**/.next/**": true,
      "**/dist/**": true,
      "**/.turbo/**": true,
      "**/.git/**": true
    },
    "search.exclude": {
      "**/node_modules": true,
      "**/dist": true,
      "**/.next": true,
      "**/pnpm-lock.yaml": true
    }
  }
}
```

把 `files.watcherExclude` 和 `search.exclude` 写在 workspace 设置里是个小窍门——比每个项目单独配 `.vscode/settings.json` 省事,而且对所有 root 同时生效。

合并完保存,以后双击这个 `.code-workspace` 文件就在一个窗口里同时打开三个项目,左侧资源管理器三个根目录并列。

### 效果

| 指标    | 三窗口分开    | 单窗口三项目       | 变化           |
| ----- | -------- | ------------ | ------------ |
| 已使用内存 | 13.89 GB | **11.97 GB** | -1.92 GB     |
| 已压缩内存 | 6.03 GB  | **3.23 GB**  | **-2.80 GB** |
| Swap  | 3.46 GB  | 3.41 GB      | ~持平          |
| 内存压力图 | 半黄半绿     | **全绿** ✅     |              |

注意压缩内存腰斩,内存压力曲线**这是整个优化过程中第一次全绿**。**单这一步省了将近 2 GB 内存**,比前面所有设置加起来都狠。

App 内存反而从 4.37 GB 涨到 5.14 GB,起初我以为这是反向优化。后来想通了——这反而是健康标志,**系统不再压缩活跃数据,让它正常驻留了**。

### 用了一段时间后的副作用观察

合并后我重点观察了几件事:

-   **Claude Code 插件**:能正确识别每个 folder 所在的项目根目录,没问题
-   **终端 cwd**:新开终端时会让你选哪个项目目录,有点烦但能接受
-   **Source Control 面板**:三个项目的 Git 状态分组清晰,不会串
-   **tsserver**:每个 root 起独立的 tsserver 进程,不会合并(这个挺关键,合成一个大的就完蛋了)
-   **Cmd+Shift+F 搜索**:默认搜所有 folder,要限定就用搜索框右上角的 "files to include"

整体下来,**用着比想象中舒服**。可能是我之前对 Multi-root 有偏见,以为多 root 会很乱,实际并不会。

* * *

## 一些细节优化(收益有限但顺手)

剩下这些是边角料,看个人需要决定要不要做:

### Nx daemon(Nx monorepo 项目)

如果项目里有 `nx`,后台会常驻一个 daemon 进程缓存依赖图,大约 185 MB。

判断标准很简单:你**经常**跑 `nx affected` / `nx graph` / `nx run-many` 吗?

-   经常 → 留着,它能让命令快几十倍
-   几乎不跑,主要靠 `pnpm dev` → 关掉

```
# 临时
npx nx daemon --stop

# 永久(项目 nx.json 里)
{ "useDaemonProcess": false }
```

### 退掉不在用的常驻 App

Claude Desktop App(~900 MB)、Insomnia(~400 MB)这种用完不退的工具,**累加起来能省 1+ GB**。要用的时候再启动,Mac 上 Cmd+Space 一秒就开起来,不必常驻。

### 每天 Cmd+Q 重启 Cursor

Electron 应用的 V8 堆**不重启不会缩**。开一天后 Renderer 涨到 700+ MB 是常态,重启回到 300-400 MB。**这是最便宜也最有效的"维护"** 。

* * *

## 战果汇总

从开始折腾到收工,整体走了这么一段路:

| 节点                 | 已使用          | 已压缩         | Swap    | 内存压力     |
| ------------------ | ------------ | ----------- | ------- | -------- |
| 起点(三窗口)            | 13.92 GB     | 6.86 GB     | 3.88 GB | 全黄       |
| 关 Cursor AI 设置后    | 13.77 GB     | 6.08 GB     | 3.46 GB | 半黄半绿     |
| **改 Multi-root 后** | **11.97 GB** | **3.23 GB** | 3.41 GB | **全绿 ✅** |

累计:**已使用 -1.95 GB / 压缩内存 -3.63 GB / 内存压力 黄→绿**

* * *

## 写在最后:几个反直觉的认知

整个治理过程,真正有用的不是某个具体的开关,而是几个**反直觉的认知**:

**1. 卡顿的源头不是 CPU,是内存换页** 所以盯着 CPU 占用看是错的,要看"已压缩内存"和"内存压力曲线"。这俩变绿,体感才会改善。

**2. App 内存升高不一定是坏事** 如果同时压缩内存下降、内存压力变绿,说明系统不再压缩活跃数据,这反而健康。

**3. 设置层有边际递减** 关 Cursor 的 Tab 和 Agent 看起来很实在,但因为这些进程是 Cursor 启动即加载的核心,你关的只是行为不是加载。**真正的杠杆在窗口数,不在设置项**。

**4. Multi-root Workspace 是 Cursor 这种 Electron IDE 多项目的最优解** 原本以为多 root 会乱,实际并不会。Claude Code、Git、tsserver 都能正确处理,体验比预期好。

* * *

## 还能再压吗?

老实说,我觉得到这个程度已经够用了。剩下能挖的:

-   副项目改用 VS Code 或 Zed(VS Code 没有 Cursor 那三个 AI 扩展宿主,单项目省 600+ MB)
-   TypeScript Project References 改造 mono-repo(让 tsserver 长期健康,这是另一篇文章的活)
-   16 GB → 32 GB(下次换机的事)

但接下来一段时间,我打算**先用着观察**——优化的终点不是省到极致,是够用 + 留出 buffer。我现在内存压力全绿,App 还有 4 GB 富余,这就够了。

折腾这一通最大的收获,可能不是省下来的那 2 GB 内存,而是终于搞清楚了 **Cursor 这种 Electron IDE 的进程模型**。以后再遇到 VS Code、Slack、Discord 这类应用的内存问题,套路是一样的——**Renderer 跟窗口数挂钩,Extension Host 跟功能挂钩,优化要对症下药**。

希望对同样在用 16GB Mac 折腾多项目的你有帮助 🙌