Cursor 越用越慢?一次「索引污染」导致的极端卡顿排查与解决

897 阅读3分钟

如果你和我一样,是 Cursor 的重度用户,那么在使用几个月后,可能会遇到一个非常折磨人的问题:

Cursor 每次回复都越来越慢,尤其是开始阶段,要等十几秒甚至几分钟,才开始输出。

如果你也遇到过类似情况,那么——你很可能和我踩中了同一个坑。


❓ 问题现象

  • Cursor 可以正常联网
  • 模型没有切换失败
  • 网络也不算差
    但就是——每次回答前卡很久

而且越用越明显。


🧠 第一步:求助大模型(结论:没用)

我首先把问题完整描述给大模型,希望从“常规经验”中找到答案。

得到的总结基本是这些:

  1. 🪜 梯子不稳定,建议买更贵的 (Cursor 是 HTTP + Streaming,没有断点续传,需要非常稳定的连接)
  2. 🌏 节点选香港 / 新加坡,离大陆近
  3. 🔁 不要自动切换节点,切换会中断流
  4. 🤖 固定使用某个模型(如 Sonnet / Opus / GPT)

我全部照做了,但情况完全没有改善。

❗ 到这里可以确认:
问题大概率不在网络,也不在模型本身。


🧑‍💻 第二步:联系 Cursor 客服(走不通)

2.1 找到官方联系邮箱

客服邮箱


2.2 发送邮件 & 初次回复

没想到 2 分钟就收到了回复,但内容比较模板化:

  • 建议使用 HTTP/1.1 或 HTTP/1.2
  • 不要使用 HTTP/2

这些我早就已经设置过了

客服回复


2.3 持续沟通

我继续补充说明现象和已排查内容,但得到的回复依然是泛泛而谈。

继续沟通


2.4 客服放弃治疗 😅

最终,对方表示暂时无法给出更多建议。

客服终止

❗ 至此可以确认:
官方支持渠道无法解决这个问题。


🔍 第三步:继续“反向”求助大模型(这次有收获)

我把前面的所有排查过程、失败经验、异常表现 完整喂给大模型,让它从系统角度重新分析。

🧠 得到的关键结论

Cursor 在本地会维护:

  • 项目级 embeddings / 索引
  • workspaceStorage
  • worktrees(Apply / Agent 用)

而我几天前做过一件事:

修改过项目名称

这可能导致:

  • worktree 指向旧路径
  • embeddings 和 workspace graph 失配
  • Cursor 每次查询相关文件时反复遍历 / 重建 / 回退

👉 最终表现为:每次回答前极长时间卡住


🛠 解决方案:彻底清理 Cursor 本地索引 & 状态

我决定直接“硬清理”。

✅ 操作步骤

⚠️ 我的系统是macOS,以下是mac的操作,windows读者需要命令行应该不同,步骤相同


1. 完全退出 Cursor

  • 菜单:Cursor → Quit Cursor
  • 确保所有窗口关闭

2. 删除 globalStorage

rm -f "$HOME/Library/Application Support/Cursor/User/globalStorage/storage.json"
rm -f "$HOME/Library/Application Support/Cursor/User/globalStorage/state.vscdb"*

这一步会强制 Cursor 重建全局存储数据库, 通常能清掉混乱的 embedding / workspace 关联关系。


3. 删除所有指向当前项目的 workspaceStorage

# 找出所有引用 project-name 的 workspaceStorage
grep -R -n "project-name" \
  "$HOME/Library/Application Support/Cursor/User/workspaceStorage"/*/workspace.json

然后把命中的目录直接删除,例如:

rm -rf "$HOME/Library/Application Support/Cursor/User/workspaceStorage/<hash>"

4. 删除 Cursor 生成的 worktrees

rm -rf "/Users/user/.cursor/worktrees/project-name"

避免 Apply / Agent 再指向旧 worktree。


5. 重新打开 Cursor(非常关键)

  • ✅ 只打开真实仓库目录
    /Users/user/Project/project-name
  • ❌ 不要打开
    /Users/user/.cursor/worktrees/...

等待 30–120 秒 让 Cursor 重新索引。


📊 效果对比

🔴 删除前

  • 磁盘块占用:6810560 × 512B ≈ 3.49GB
  • 逻辑大小:1736814592B ≈ 1.62GB

删除前


🟢 删除后(重建索引)

磁盘块占用和逻辑大小,数值下降 3–4 个数量级(千分之一到万分之一)。

Cursor 秒回,完全不卡。

删除后


⏱ 重度使用 10 天后

  • 磁盘块占用和逻辑大小,上升约 2 个数量级
  • 体量仍然只是原来的 几十分之一
  • 使用体验依旧 丝滑、秒回

10天后


✅ 终于

通过一次彻底清理,我的 Cursor 满血复活。


以上,供大家参考,欢迎讨论
如果你也遇到类似问题,希望这篇文章能帮到你。