一下午都在 Composer 里来回迭代，晚上关掉 Cursor，第二天早上一打开——对话列表空了。或者只剩今天的一条，昨天那条深聊就这么没了。有时甚至不用完全退出，reload 一次窗口就丢。Cursor 的聊天历史存在你用户目录下的本地 SQLite 里；丢的话几乎都是这几种原因之一：Composer 历史是按 workspace 区分的，你开错了文件夹；硬关导致 SQLite 文件损坏；账号同步把线程拉到云上拉出错；或者清理任务为了控制磁盘悄悄裁掉了旧对话。能不能恢复看情况，但预防是非常便宜的。
常见原因
按命中率从高到低。
1. Composer 历史按 workspace 分，你开错了文件夹
Composer 对话和创建它的 workspace 绑定。打开了同级目录或不同的 worktree，前一个 workspace 的历史就看不到——没删，只是 out of scope。
怎么判断：File → Open Recent → 切回原来那个目录。线程都回来了——就是它。
2. SQLite 历史文件损坏
硬关（Composer 正在写的时候 force quit）会让 SQLite WAL 留在 Cursor 恢复不了的状态。下次启动就直接建新库，不报错。
怎么判断：看 ~/Library/Application Support/Cursor/User/workspaceStorage/<hash>/state.vscdb（macOS）里有没有残留 state.vscdb-shm 或 state.vscdb-wal。出现 .backup 文件也是强信号。
3. 账号同步偷偷搬动了线程
Cursor 的「Sync chat history」会在设备之间搬线程。一次坏的同步可能从另一台机器拉数据、把本地线程盖住。
怎么判断：Settings → Account → Sync chat history → 关掉、重启，看本地线程回不回来。回来后再开。
4. 撞到本地历史保留上限
Cursor 每个 workspace 存的对话有上限（最近版本是 100-200 条）。超了之后旧的会被静默裁掉。
怎么判断：数一下当前线程数。正好在上限附近、丢的恰好是最旧的——就是它。
5. 项目从不同的绝对路径打开了
Composer 用 workspace hash 给存储分桶，hash 包含绝对路径。symlink、网络盘重挂、~/Projects 变成 /Users/you/Projects——都会生成新 hash，对应一份空历史。
怎么判断：对比今天和昨天标题栏里的路径。哪怕只是表面差异都会把存储劈开。
6. Cursor 升级时迁移存储漏了一些
偶尔大版本升级会迁移存储 schema，漏掉一些。少见，但 major 版本时确实发生过。
怎么判断：Help → About 看版本。去 changelog 里搜 storage migration 这条。
开始前
- 别在空的 Composer 里开新对话——新写入可能盖掉能恢复的备份。
- 弄清楚丢失历史的那个 workspace 确切路径。
- 动存储文件前先完全退出 Cursor，正在写的时候去碰会把恢复机会也毁了。
需要收集的信息
- Cursor 版本（Help → About）。
- OS 和用户数据目录路径。
- 准确的 workspace 路径（今天的 vs 创建历史的那个）。
- 「Sync chat history」是不是开着。
~/Library/Application Support/Cursor/User/workspaceStorage/下的文件（Linux:~/.config/Cursor/User/...，Windows:%APPDATA%\Cursor\User\...）。- 丢失线程大概数量和时间范围。
一步一步修复
Step 1：开回原来那个 workspace
File → Open Recent，选项目的原始路径，精确点。历史回来——就是开错文件夹了。以后把规范路径加书签。
Step 2：toggle 同步重新拉
Settings → Account → Sync chat history → 关、重启、开、再重启。强制重拉一次。云上有的丢线程会回来，从没同步过的不会。
Step 3：到磁盘上看 workspaceStorage
完全退出 Cursor。列目录：
ls -la ~/Library/Application\ Support/Cursor/User/workspaceStorage/每个子目录是一个 workspace hash。你项目对应的那个里会有 state.vscdb。文件几 KB 以上一般有数据；接近 0 就是空的。
Step 4：从 backup 文件恢复
如果看到 state.vscdb.backup 或 state.vscdb-corrupted，先把现在的 state.vscdb 留一份（以防万一），然后把 backup 改名成 state.vscdb 再启动 Cursor：
cd ~/Library/Application\ Support/Cursor/User/workspaceStorage/<hash>/
cp state.vscdb state.vscdb.broken
mv state.vscdb.backup state.vscdbStep 5：打开 SQLite 看看里面
没 backup 的话，库里可能也还有数据。Cursor 退出状态下：
sqlite3 state.vscdb "SELECT key FROM ItemTable WHERE key LIKE '%composer%' OR key LIKE '%chat%';"有匹配 key 就说明数据还在。把 value 导成 JSON，然后开 Cursor 看它能不能识别。
Step 6：globalStorage 也查一下
部分聊天元数据在 ~/Library/Application Support/Cursor/User/globalStorage/。找 cursor.aichat.* 目录。把过期的那个挪走再重启，能逼 Cursor 从更健康的源头重建。
Step 7：兜底——开 support ticket
数据是在 Pro 账号 + 同步开着的情况下丢的，Cursor support 有时能从云快照恢复。带上版本、workspace 路径、大致日期、Step 3 里看到的文件大小。
怎么验证修好了
- 打开恢复后的 workspace，对比线程标题和你记得的一致。
- 点进一条旧线程，确认对话完整、没截断。
- 重启 Cursor 一次，历史扛得住重启。
- 同步开关切一轮，没线程丢失。
长期预防
- 退 Cursor 用 Cmd+Q（macOS）或 File → Exit，能避免 force-kill 就避免。
- 跨设备用就把「Sync chat history」开着——这是你的远端备份。
- 项目用稳定的绝对路径，有 Composer 历史之后就别挪文件夹了。
- 不可替代的重要对话，导出一份：点线程 → Export → 存成 Markdown。
- 定期用 Time Machine 或 rsync 备份
~/Library/Application Support/Cursor/User/workspaceStorage/。
容易踩的坑
- 空窗口里先开新对话再去查 workspace 路径，新写入可能盖备份。
- Cursor 开着改 SQLite 库，一定要先退出。
- 以为云同步啥都有。同步只覆盖开启之后的；之前的可能根本没上传。
- 项目用到一半改文件夹名，workspace hash 一变，活跃线程立刻从侧边栏消失。
- 把「Reload Window」当无副作用操作。它会重新 init 状态、有时会把陈旧路径暴露出来。
常见问答
- Cursor 聊天到底存哪？ macOS：
~/Library/Application Support/Cursor/User/workspaceStorage/<hash>/state.vscdb。Linux 和 Windows 在各自的 per-user app 目录下镜像。 - 会同步到 Cursor 账号吗？ 只在你打开「Sync chat history」之后才会。即使开了，超大对话可能被延迟或裁掉。
- 能单独导出一条对话吗？ 能——打开线程，点三点菜单 → Export。
- 同一个项目通过 symlink 打开会和真实路径共享历史吗？ 不会，workspace hash 不一样，两份独立存储。
- 保留上限大概多少？ 0.46 大约每 workspace 100-200 条。重度用户要把重要的导出来。