报错现象

Cursor 用了一段时间后越来越卡，通常不是错觉。先按三种典型形态对号入座，后面的排查路径取决于你命中哪一种。

形态一，索引折腾型：状态栏反复出现 Indexing、Syncing 字样，久久不消失；每切换一次工作区就重新来一遍，聊天时的语义检索也跟着失灵。

形态二，内存膨胀型：任务管理器里 Cursor 相关进程合计常驻两三个 GB 起步，随使用天数只涨不跌；输入出现肉眼可见的延迟，Tab 补全转圈。

形态三，渲染掉帧型：CPU 占用不高，但滚动、切换面板明显掉帧，风扇起飞——这类多半出在 GPU 渲染链路，而不是代码索引。

对照清单（逐条核对你机器上的表现）：
- 状态栏反复出现 Indexing… / Syncing…，迟迟不到 indexed
- Cursor.exe 及其子进程合计内存 2~3 GB 起步并持续上涨
- 输入延迟肉眼可见，补全提示转圈半秒以上
- 滚动掉帧、窗口拖动有残影，同一屏幕上的其他应用却正常

任务管理器中 Cursor 各进程的 CPU 与内存占用（截图占位）

以上是通用形态。本文案例机器上的具体数值与截图以实测为准【待补：把你机器上的状态栏截图与任务管理器占用数值填进来】。

环境

  • 系统：Windows 11。路径写法以 Windows 为例，macOS 的对应关系在文中随用随给
  • Cursor：版本号【待补：Help → About 里查看并填写】。Cursor 是 VS Code 的 fork，VS Code 的性能排查手段与设置项基本原样适用，这是整篇排查的底层逻辑
  • 示例项目：一个中型 monorepo，含前端、后端与若干生成物目录【待补：补上你仓库的 git 文件数与语言构成】

排查过程

排查原则：先定位是哪个环节慢，再动手。顺序从便宜到贵，别一上来就重装。

第一步，确认是 Cursor 慢而不是机器慢。用 VS Code 打开同一个仓库对比体感；如果 VS Code 也卡，先查系统层面——磁盘快满、杀毒软件实时扫描开发目录，都是常见的背景拖累。

第二步，看进程。Ctrl+Shift+P 打开命令面板，执行 Process Explorer（VS Code 同源命令），它会展开主进程、扩展宿主（extension host）、各语言服务、GPU 进程、文件监听器的实时 CPU 与内存。谁在吃资源一目了然：extension host 偏高通常是扩展的事；tsserver 在大仓库里内存过 1 GB 属正常量级；gpu-process 偏高对应掉帧形态。定位到的具体进程与数值【待补：填你机器上的实测结果】。

第三步，量缓存。关闭 Cursor 后用 PowerShell 统计两块目录的体积：

# 用户数据目录：设置、会话历史、workspaceStorage、各类缓存
Get-ChildItem "$env:APPDATA\Cursor" -Directory | ForEach-Object {
  $size = (Get-ChildItem $_.FullName -Recurse -File -ErrorAction SilentlyContinue |
           Measure-Object -Property Length -Sum).Sum / 1MB
  "{0,10:N1} MB  {1}" -f $size, $_.Name
} | Sort-Object -Descending | Select-Object -First 15

# 扩展目录：第三方扩展装在这里，装太多也会拖慢启动
Get-ChildItem "$env:USERPROFILE\.cursor\extensions" -Directory |
  Select-Object Name, LastWriteTime

Cache、CachedData、Code Cache、GPUCache、Service Worker 这几项加起来超过 2 GB，是长期使用后的常态（Electron 应用的公认量级）。实测数字【待补：填你的统计结果】。

第四步，看索引状态。设置里找 Indexing 相关面板（不同版本的入口名称与位置有差异【待补：填当前版本的准确入口名】），逐个仓库确认状态是 indexed 还是反复 syncing。如果某个几十万文件的生成物目录没被排除，每次打开项目都会触发一轮无效的重算——这是”越用越卡”最常见的推手。

第五步，怀疑扩展。二分法做 A/B：禁用一半扩展，重载窗口对比启动速度与内存；再对另一半重复。必要时看命令面板里的 Startup Performance 报告，它会把启动耗时按扩展拆开。

根因分析

按命中概率从高到低，“越用越卡”基本落在五条里：

  1. 索引范围失控。build、dist、coverage、测试数据这类目录没进忽略名单，索引反复扫描重算。Cursor 会尊重 .gitignore，但很多仓库的生成物并不在 .gitignore 里，这是盲区。
  2. 缓存与状态累积。Electron 系应用的 Cache 类目录只进不出，涨到数 GB 后读写放大；workspaceStorage 随工作区数量和会话历史持续增长，拖累每次启动。
  3. 语言服务内存。大仓库里 tsserver 常驻内存上 GB 属正常量级，再叠加扩展宿主，可用内存吃满后系统开始换页——卡的体感多半来自换页，而不是 Cursor 本身。
  4. 文件监听风暴。watcher 没排除生成目录，构建脚本一跑，成千上万个文件变更事件灌进主进程。
  5. GPU 渲染问题。显卡驱动与 Electron 合成器不合拍，特征是 CPU 不高但 UI 掉帧。

修复

对症下药，按你定位到的根因执行对应项；拿不准就按顺序全做，成本都不高。

第一项，把生成物挡在索引外。仓库根目录建 .cursorignore（语法同 .gitignore，作用是把目标同时排除出语义索引和 AI 上下文）：

# .cursorignore：不参与索引、不进入 AI 上下文
dist/
build/
coverage/
**/*.snap
*.min.js
data/
fixtures/

第二项，排除监听与搜索。settings.json 里补上 VS Code 同源的配置：

{
  "files.watcherExclude": {
    "**/dist/**": true,
    "**/build/**": true,
    "**/coverage/**": true
  },
  "search.exclude": {
    "**/dist": true,
    "**/package-lock.json": true
  },
  "editor.largeFileOptimizations": true
}

第三项，重建索引。设置里执行 Resync Index，让忽略规则生效后从头算一遍，别指望增量同步替你追溯旧规则。

第四项，清缓存。关闭 Cursor 后执行。Cache 类目录删除后会按需自动重建，是安全的；workspaceStorage 不要删，删了会丢对应工作区的会话历史：

# 关闭 Cursor 后执行；以下目录删除后会自动重建
$dirs = @("Cache", "CachedData", "Code Cache", "GPUCache", "Service Worker")
$dirs | ForEach-Object {
  Remove-Item -Recurse -Force (Join-Path "$env:APPDATA\Cursor" $_) -ErrorAction SilentlyContinue
}

第五项，只对掉帧形态做：命令面板执行 Preferences: Configure Runtime Arguments，在打开的 argv.json 里加 “disable-hardware-acceleration”: true（VS Code 同源机制），重开窗口。副作用是动画变朴素，换取流畅。

第六项，扩展瘦身：长期不用的扩展直接卸载而不是禁用，减少扩展宿主的常驻负担。

验证

修复后按与排查相同的口径复测：

  1. 重跑第三步的统计命令，Cache 类目录应回到百 MB 量级【待补：清理前后体积对比】；
  2. 重开项目，等索引完成后状态栏稳定在 indexed，不应再反复 syncing【待补：重建索引用时】；
  3. Process Explorer 里 extension host 与 tsserver 回到合理水位【待补：修复后的进程级实测数值】；
  4. 输入延迟与滚动掉帧是否消失——连续使用半天再下结论，别刚重载完就验收。

四条全绿才算修复完成。只清了缓存但索引范围没修的，两周后还会复发。

如何预防

  • 新仓库第一次打开前，先补 .cursorignore，再让索引开工；
  • 生成物目录一律进忽略名单，并把这条写进 code review 的检查项；
  • 每月清一次 Cache 类目录，清理脚本直接放进仓库的 scripts 目录，谁都能跑；
  • 同时打开的工作区窗口控制在少量几个，不用的会话及时关；
  • 升级前先看官方 changelog，确认没有已知的性能回归再更；升级后若立刻变卡，回到本文排查流程走一遍。

相关阅读