Cursor 卡顿、吃内存：performance 页给的判定顺序
翻 Cursor 官方帮助文档的 cursor.com/help/troubleshooting/performance 这一页，第一反应大概是「就这么点？」。整页只有三个小标题，处置手段来回就是禁用扩展和往 .cursorignore 里加目录两条。
但这页的价值不在篇幅，而在于它替你做了分类。性能问题最容易犯的错，是把一堆症状糊成一句「Cursor 好卡」，然后随手关几个扩展、清一遍缓存，好了不知道为什么好，没好也不知道下一步动哪里。官方把它切成三类，各自的判定动作与处置不同——这份分类本身就是排查顺序。
下面按实际次序走一遍：怎么确认是它、文档给的处置是什么、处置完怎么验证、什么情况说明根本不是这一类。
先分类：官方只承认三类性能问题
performance 页的三个小标题，逐字对应三个问题：CPU 或内存占用过高、代码库索引慢、编辑器输入延迟。这三条是回源数过的，页面里没有第四类。
分类的意义在于，三类的观察对象不一样：
- CPU / 内存占用高 —— 观察对象是系统的进程资源，文档把成因指向扩展与设置；
- 索引慢 —— 观察对象是仓库首次进入可用状态的等待过程，文档自述「对大仓库来说，初次索引会花时间」；
- 输入延迟 —— 观察对象是敲键盘到字符上屏这一段，文档给的处置同样落在扩展上。
如果你的症状对不上这三条中的任何一条——比如是「AI 回复半天不来」「Tab 建议不出现」「启动白屏」——那就不该在这一页找答案，后面会说该去哪一页。这一步分错，后面全白做。
第一类：CPU 或内存占用过高
现象：机器风扇起飞、整机发闷，任务管理器（Windows）或活动监视器（macOS）里 Cursor 相关进程占用明显偏高。
怎么确认：官方文档在这一条下写明「高占用通常源于扩展或设置问题」，并给出一条可直接执行的判定动作——用不带扩展的方式启动，看占用是否回落：
cursor --disable-extensions
这条命令是从官方 performance 页原样抄的，文档写的是「从命令行运行 cursor --disable-extensions 来测试」。至于该命令在各平台上如何进入 PATH，这一页没有说明。命令行参数与其行为随版本变动，以官方文档与 --help 的实际输出为准。
如果你更习惯不出命令行，cursor.com/help/troubleshooting/extensions 这一页写明了另一条等价路径：打开命令面板，搜索 Disable All Installed Extensions；单个扩展的禁用，官方文档写明是在 Extensions 面板里找到它然后点 Disable，面板的快捷键是 Windows / Linux: Ctrl + Shift + X，Mac: Cmd + Shift + X。cursor.com/help/customization/extensions 那一页还写明，禁用可以选全局，也可以只对当前工作区生效——排查阶段建议用后者，免得把别的项目一起搞乱。
文档语义给出的处置，一共两条：
- 禁用你不需要的扩展。文档写明的方法是先用
--disable-extensions测试，然后一次重新启用一个，用来定位到底是哪个扩展。 - 把大型的生成目录加进
.cursorignore，文档举的例子逐字是dist/、build/、.next/。
第二条容易被当成「只跟索引有关」而跳过——但它就写在「如何降低高 CPU 或内存占用」这一节下面，是这一页给占用问题开出的第二味药。
处置后怎么验证：验证动作就藏在处置里——逐个重新启用。启用到某一个之后占用又上去了，那个就是原因；全部启用回来占用都正常，说明刚才的高占用不是扩展造成的（或者已经被另一条处置连带解决了）。这个「一次一个」的纪律很枯燥，但一次性全开回去，你等于把刚做完的判定作废了。
什么情况说明不是这个原因：在完全不带扩展的会话里占用依然高，那么扩展这条线可以划掉，别再一个个试了。另外要说清楚的是，performance 页没有给出任何占用数值的参考线，也没有说明 Cursor 自带哪个界面可以查看资源占用——「多高算高」这件事，官方文档在这一页没有说明，只能靠你自己跟平时的基线比。
第二类：代码库索引慢
现象：大仓库刚打开，索引迟迟不完成。
怎么确认：这一类的判定动作不是看进度，而是看排除范围配得对不对。官方给的两条都是配置检查：
- 把生成的代码和构建产物加进
.cursorignore； - 确认
node_modules之类的依赖目录在.gitignore里——文档在这里补了一句关键语义：Cursor 的索引会遵循.gitignore。
也就是说，如果依赖目录本来就被 git 忽略了，你不需要在 .cursorignore 里重复写一遍；cursor.com/help/customization/ignore-files 那一页把两者的分工说得更直白：.cursorignore 是用于 .gitignore 覆盖不到的额外排除项。先去看 .gitignore，再决定 .cursorignore 补什么，顺序反了会写出一堆冗余规则。
.cursorignore 的写法，官方文档给的示例逐字是这样：
node_modules/
dist/
*.min.js
.env*
同一页还写明，Cursor 默认已经忽略 .env 文件、.git/ 和 lock 文件，完整的默认忽略清单在官方的 ignore file 参考页。
这里有一条边界必须照实说，它跟性能无关但同一页写明了：被忽略的文件会被挡在索引和 Agent 之外，但终端命令和 MCP 工具运行在 Cursor 的文件访问控制之外，它们仍然可能读到这些文件。所以别把 .cursorignore 当成密钥的隔离手段用。
处置后怎么验证：这一点得实话实说——performance 页没有说明索引进度在哪里查看，也没有给出「索引完成」的判定信号。文档能支撑的验证只有间接的：改完忽略规则之后，第一类现象（占用）是否回落。索引本身的可观测性，这一页没写。
什么情况说明不是这个原因：文档自述初次索引对大仓库「会花时间」，所以刚 clone 完的大仓等一会儿属于预期内，不必立刻当故障处理。另外，如果你的症状是「AI 回答里没有引用到某些文件」，那更可能是忽略规则写过头把有用的目录也排掉了，方向正好相反；需要精确指定上下文时，cursor.com/help/customization/context 写明可以用 @ 提及具体文件与文件夹。
第三类：编辑器输入延迟
现象：敲字上屏发滞。官方文档把这一条单列为「编辑器输入延迟」，与 Chat、Tab 这些需要联网的功能分在不同的小节里；至于两者在实现上是否互相牵连，文档没有说明这一点。
怎么确认与处置：这一类官方给的内容最短，且与第一类同源——逐个禁用扩展来定位原因，同样可以用 cursor --disable-extensions 在不带任何扩展的状态下测试。换句话说，第一类和第三类的判定动作是同一个，做过一次就不用重来。
什么情况说明不是这个原因：这里是最值得区分的一处。Tab 补全慢或不出现，不属于 performance 页的范围。 cursor.com/help/troubleshooting/tab-issues 单独列了一页，它给出的原因清单里包含套餐用量已用完（文档写明免费档的 Tab 用量有月度额度，用完会暂停到下个计费周期，具体数值本文不写）、网络屏蔽 HTTP/2、版本过旧、以及根本没有联网——Tab 需要连接才能工作。这一页还写明 VPN 和代理会带来额外延迟。这些都是网络与账号侧的因素，跟本地输入延迟不是一回事，用禁用扩展的办法去治它属于走错门。
什么情况说明整件事都不是性能问题
这是排查里最省时间的一步，先做这一步能避免大量无用功。以下症状在官方帮助文档里各有专页，都不在 performance 页的三类之内：
| 症状 | 该去哪一页 | 官方文档写明的入口 |
|---|---|---|
| 启动白屏、启动失败 | help/troubleshooting/install-issues | Windows 上以管理员身份运行 Cursor；命令面板运行 Clear Editor History 重置缓存状态 |
| AI 功能连不通、走代理后失效 | help/troubleshooting/network | Cursor Settings > Network > Run Diagnostics；将 HTTP Compatibility Mode 设为 HTTP/1.1 后重启 |
| 远程 SSH 场景下 AI 功能异常 | 同上 | 文档写明 AI 请求是从本地机器发往服务端，而不是从远程主机发出 |
远程这一条特别容易误判成性能问题：network 页写明，远程主机的内存或 CPU 耗尽会导致连接掉线，而且 SSH 会话断掉之后可能留下残留进程，官方给的处置是重连后完整重启 Cursor。你在本地看到的「卡」，源头可能在远端那台机器上，禁用多少个扩展都没用。
Windows 侧还有一点值得单独记：install-issues 页给的 Windows 处置是以管理员身份运行，而 macOS 那几条（拖到废纸篓重装、「Cursor is damaged」告警的处理）在 Windows 上根本不适用，别照着 macOS 的步骤瞎试。
三类都排完还是定位不了
那就按 cursor.com/help/troubleshooting/reporting-bugs 给的清单准备材料，别只发一句「很卡」。这一页写明报告里应包含：Cursor 版本（官方文档写明在菜单栏 Cursor > About Cursor 查看）、操作系统及其版本、复现步骤、期望行为与实际行为、Request ID，以及 Help > Toggle Developer Tools 里的控制台报错。
Request ID 的取法，文档写明是在 Chat 侧栏打开相关会话、点上下文菜单（”…” 菜单）、选 Copy Request ID。同一页还写明一条容易踩的时序问题：Privacy Mode 是按请求生效的，改设置不会追溯已经发生的请求——出问题时是隐私模式，事后切成 Share Data 也捞不回那次请求的细节。要提供更多上下文，得在切换之后重新复现一次再取新的 Request ID。
最后说三句实在话
第一，这一页给的处置只有两味药——扩展和忽略规则，所以别指望在这里找到调优参数。这一页里没有出现任何内存上限、缓存大小、索引线程数之类的配置项，一个都没有；看到别处传的「某某设置能让 Cursor 省内存」，先回官方文档核一遍是不是真的存在这个设置。
第二，判定纪律比手段重要。这一页真正可复用的东西是「一次只改一个变量、改完立刻验证」，--disable-extensions 只是这条纪律的一个载体。
第三，Cursor 迭代频繁，这里提到的设置项、命令与页面结构都会随版本变动，以官方文档最新内容为准。
本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。
该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现；
我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。
该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。
本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。
安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。