# Cursor 让 Mac 卡顿？排查 CPU 和内存占用

> 通过测试扩展、工作区范围和生成文件来诊断 Cursor 的 CPU 和内存使用，不删除项目数据或聊天记录。

Published: 2026-10-23 | Updated: 2026-10-25

Cursor 可能因几个不同原因让 Mac 变慢：正在运行的扩展、正在处理的大型工作区、长时间运行的 AI 任务，或任务停止后仍持续占用内存的进程。先找出哪个操作让占用升高。缓存文件夹大并不能证明删除它就能解决 CPU 占用问题。

## 用同一操作做对比

保存项目并记下 Cursor 的版本。打开**活动监视器**，搜索 Cursor，对比打开项目前、复现问题期间和任务停止后的 CPU 与内存。每次测试都使用同一个仓库和同一个操作。

如果小文件夹表现正常而 monorepo 不正常，工作区范围就是一条有用的线索。如果新聊天响应正常而某个长对话不正常，要单独测试。如果在重复负载下占用持续上升，记录增长量和经过时间。仅凭一次较大的读数不能确定存在内存泄漏。

## 先分清是编辑器还是后台任务

一个 Cursor 会话可能包含编辑器窗口、扩展、语言服务器、终端和一个 AI 任务。其中一些工作可以在编辑器空闲时继续运行。在禁用任何内容之前，检查是否仍有终端在运行构建、持续运行的测试任务、开发服务器或模型。只通过终端或应用的正常控制停止你认得出来的任务，并先保存它的工作。

在活动监视器中，在三个时间点比较忙碌的进程：工作区已打开但未开始任务时、在感觉缓慢的操作期间、以及该操作结束后。记录进程名称，以及症状是输入延迟、高 CPU 还是内存增长。仅凭辅助进程的名称很少能确定负责的扩展，因此用后续比较来缩小范围。

尝试打开实际的项目文件夹，而不是包含多个仓库的父文件夹。不要为了执行此测试而移动或删除项目。如果较小的工作区改善了结果，确定更宽泛的工作区包含了什么：生成的资源、另一个项目的依赖、正在监听文件变化的任务，或扫描更多文件的语言工具。这说明工作区范围值得检查，不代表所有大目录都该排除。

例如，反复写入输出的开发服务器可能是编辑器观察到的活动工作。排除文件夹和停止该服务器测试的是不同的解释。同时更改两者会失去区分，因此记录哪一个单独更改影响了重复的操作。

## 在重置编辑器之前测试扩展

Cursor 的[性能指南](https://cursor.com/help/troubleshooting/performance)建议在禁用扩展的情况下运行一次。保存工作并正常退出 Cursor 后，从终端启动：

```
cursor --disable-extensions
```

这假定已安装 `cursor` shell 命令。如果不可用，使用 Cursor 的扩展视图禁用非必要扩展来进行对比。记下禁用的扩展，测试后可以恢复。

重复同一个项目操作。如果情况改善，逐个恢复扩展，直到症状重新出现。如果没有改善，恢复之前的扩展状态并继续。不要将打开不同文件的测试当作排除扩展的证据，也不要下一步就删除整个用户数据目录。

## 禁用扩展有效后，继续找出具体扩展

如果禁用扩展后的运行改善了同一操作，不要重新安装所有扩展或丢弃它们的设置。从记录的已启用集合开始，在候选很少时一次恢复一个。扩展很多时，一次恢复一半可以更快地缩小范围，前提是每次测试都打开同一项目并完成同一操作。

分组测试能缩小范围，但不一定只有一个扩展出了问题。两个扩展可能相互作用，禁用语言扩展也可能移除触发工作负载的功能。一旦出现候选，在启用你实际需要的所有扩展、只禁用该候选的情况下重复测试。同时检查代码补全、诊断、构建和操作是否流畅。

如果最终比较仍指向一个扩展，记录其名称和版本。如果提供按工作区禁用的选项，可以先只对当前项目禁用，避免影响其他项目。如果禁用它破坏了所需功能，请恢复它，并为其维护者保留复现步骤，而不是把更快但不完整的编辑器当作期望结果。

## 排除不需要的生成输出

AI 辅助工作可能产生构建输出、导出的包、生成的图像和大型日志。如果打开的是所有项目的父文件夹，工具可能会处理许多与当前任务无关的文件。先打开实际的项目根目录。

Cursor 记录了 [`.cursorignore`](https://cursor.com/docs/reference/ignore-file)，用于限制 AI 对项目文件的访问，终端和 MCP 工具除外。其性能指南建议排除大型生成文件夹。这会影响 AI 访问文件的范围，不只是索引，也不能阻止所有语言服务器或文件系统监视器。

对于这些目录确实是生成输出的项目，`.cursorignore` 文件可以包含：

```
dist/
build/
.next/
```

先检查文件夹并保留现有的忽略规则。项目中名为 `build` 的目录可能包含人工维护的构建脚本。添加模式不会删除文件，但会让 AI 功能读不到本来有用的上下文。之后重新检查索引状态和同一个编辑器操作。

## 根据结果继续排查

| 观察结果 | 接下来调查什么 |
| --- | --- |
| 禁用扩展后问题消失 | 逐个恢复扩展 |
| 只有大型工作区触发 | 项目根目录、生成输出和语言工具 |
| AI 任务结束后 CPU 回落 | 任务负载和并发 |
| 同一重复操作期间内存持续增加 | 记录版本、时间和复现步骤 |
| 整个 Mac 变慢 | 内存压力和其他活跃应用 |

[Mac 内存压力指南](https://mole.fit/zh/blog/mac-memory-pressure-explained)解释了为什么仅看已用内存不是可靠的警报。关闭不用的工作区可以减少当前负载，不需要删除其中的文件。

## 检查忽略规则是否影响正常工作

更改 `.cursorignore` 后，检查文件差异，重新执行卡顿的操作，再问一个涉及项目中正常代码的问题。更小的可见项目上下文只有在 Cursor 仍拥有任务所需源代码时才有用。如果新模式排除了重要内容，只移除该新模式；不要用空文件替换整个忽略文件。

几类规则需要分清。Git 忽略规则管理 Git 对未跟踪文件的处理。Cursor 的 AI 访问排除管理文档中记录的 AI 功能。语言服务器、扩展或终端里的文件监听任务有自己的行为。在没有识别出忙碌组件的情况下到处添加相同模式可能掩盖症状并移除有用功能。

如果 CPU 正常但答案到达缓慢，将 AI 请求与编辑器资源使用分开调查。如果每次重复时内存都增长，即使工作结束后也是如此，按相同条件记录几次内存用量和间隔时间，然后测试重新打开工作区是否会改变该模式。这对维护者来说比报告构建期间看到的最大数值有用得多。

## 仅在磁盘空间是问题时清理磁盘残留

Cursor 缓存、旧工具版本、会话历史和工作树有不同的归属和恢复方式。工作树可能包含未提交的更改或仅存在于那里的提交。聊天历史可能是你仍然需要的工作。

使用 [AI 编码工具清理指南](https://mole.fit/zh/blog/how-to-clean-up-ai-coding-tools-mac)处理磁盘占用问题。对于持续的 CPU 或内存问题，向 Cursor 发送最小可复现案例、版本和扩展对比。分享前检查日志，因为它们可能包含项目名称或代码。这样才能围绕卡顿本身定位问题。

---

Canonical HTML page: https://mole.fit/zh/blog/cursor-high-cpu-memory-mac
Blog index for agents: https://mole.fit/zh/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt