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 相关的进程拎出来:

scss 复制代码

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。它的进程结构是这样的:

scss 复制代码

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

要做三件事:

每个项目分别 Delete Index------切到对应窗口才能删,不是全局操作
关闭 Index New Folders------以后新项目不再自动索引
关闭 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 套)

操作很简单:

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

我的 workspace 文件大概长这样:

json 复制代码

{
  "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 → 关掉

bash 复制代码

# 临时
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 折腾多项目的你有帮助 🙌