怎么说呢，

为什么要写这篇

Cursor 的对话数据被埋在 SQLite 数据库里却没有任何官方文档、schema 说明。甚至连表名都不遵循常规命名。很多人在实现 Cursor 适配器时会踩到一样的坑——找不到对应的表、键值格式莫名其妙、数据分散在多个文件中…，话说回来，这篇文章把最常见的痛点和对应的方法全部记录下来帮助你少走弯路。

至于坑一，两个数据库。数据分散

很多人误以为只需要打开一个数据库文件就能拿到全部对话。Cursor 把数据拆成了两块：

~/.config/Cursor/User/
├── workspaceStorage//state.vscdb ← Composer 元数据
└── globalStorage/state.vscdb ← 对话内容

关键痛点：元数据和具体对话内容不在同一个库里导致单库查询必然缺失信息。

对话」；老实说，全局数据库记录「每条对话说了什么」。正确的流程是先从工作区库取到 composerId再去全局库通过该 ID 查询对应的 bubble。

# 工作区 DB
composer.composerData → { allComposers: }
# 全局 DB
cursorDiskKV → key: "bubbleId:abc:" → value: { type: ...。text: "你好" }
cursorDiskKV → key: "bubbleId:abc:" → value: { type: ...,text: "你好！有什么..." }

坑二的观点是，表名是 camelCase 而非 PascalCase

VS Code 系 IDE 的 SQLite 表名通常是 ItemTable但 Cursor 在全局 KV 存储里使用的是 cursorDiskKV。如果直接复用 VS Code 示例代码，就会遇到「no such table」错误。

-- 工作区 DB
SELECT value FROM ItemTable WHERE = 'composer.composerData';其实，-- 全局 DB
SELECT。value FROM cursorDiskKV WHERE LIKE 'bubbleId:abc:%';

痛点

• 误用 ItemTable 查询全局 KV → 报错「no such table」。话说回来，
• 必须明确区分两种表名并使用对应的 SQL。

坑三的观点是，key 格式是多段冒号分隔

全局库里每条 bubble 的键采用多段冒号分隔的形式：

bubbleId::

示例这方面。bubbleId:abc123:def456

常见痛点：直接使用等号 匹配会漏掉大多数记录，需要改用前缀匹配。

SELECT,value FROM cursorDiskKV
WHERE LIKE 'bubbleId:abc123:%';

如果想从键中抽取出所有唯一的 composerId可以利用 SQLite 的字符串函数：

SELECT DISTINCT
SUBSTR(。INSTR + 1,-- 跳过第一个 "bubbleId:"
INSTR + 1),':') - 1
) AS composerId
FROM cursorDiskKV
WHERE LIKE 'bubbleId:%';

从坑四来看，schema 版本字段 _v 会变动

bubble 数据中有一个叫做 _v 的字段，用来标记 schema 版本：

{
至于"_v"。1,"type": "assistant","text": "帮我看看这段代码"
}

Pain point：Cursor 更新后可能出现新版本（如 "_v": 2)，旧解析逻辑若直接假设固定结构会抛异常。推荐在解析时加入版本检查并给出警告，而不是让程序崩溃。

if {
console.warn;}

坑五的观点是。 空助手消息是流式中间态

C​ursor 在生成 AI 回复时会先写入一个空壳 bubble，接下来逐步填充文本。如果对话被意外中断，这些空壳可能永远不会被填满。不过，

{
"_v"这方面，1,"type": "assistant","text": ""。"createdAt": "2024-10T10:01Z"
}

Pain point：若但是滤这些空 bubble，导出的对话会出现大量无意义的空行。

if continue;// 跳过空助手消息

从坑六来看。孤立对话不会自动消失

当你删除了某个项目目录后对应的工作区数据库也随之消失，但全局数据库里的 bubble 数据仍然保留。这些没有关联工作区 entry 的记录称为「孤立对话」。如果直接忽视，它们会导致导入结果出现「未知项目」或重复项。

Pain point：需要额外一步扫描全局库、过滤已知 composerIds，并仅保留至少包含一条有实际文本内容的孤立对话。

1. 扫描全局库所有键，以 bubbleId: 为前缀。

// 从 key 中提取所有 composerId
const result = db.exec(
`SELECT DISTINCT SUBSTR(。INSTR + 1,INSTR + 1),':') - 1) AS composerId
FROM cursorDiskKV WHERE LIKE 'bubbleId:%'`
);// 排除已经在工作区出现的 ID
const candidates = result.values
.map
.filter);// 检查是否存在实际内容
for {
const bubbles = db.exec(
`SELECT value FROM cursorDiskKV
WHERE LIKE 'bubbleId:${composerId}:%' LIMIT 10`);const hasContent = bubbles.values.some(row => {
const b = JSON.parse;return .trim.length> 0;})，if valid.push;}

坑七的观点是，thinking 块有多种格式

Cursor 在思考过程里使用了 “allThinkingBlocks” 数组。但每个块可能使用不同字段：

{ “allThinkingBlocks”: } 

解析时必须兼容两种字段，也要兼容旧版直接在根对象上的 “thinking”。

if {
const thinkingTexts = bubble.allThinkingBlocks
.map
.filter;if {
thinking = thinkingTexts.join;}
} else if {
thinking = bubble.thinking;}

再看坑八，workspace.json 的方法是 URL 编码

工作区中的项目方法存放在 workspace.json 中。但它们是经过 URL 编码的：

{ “folder”: “file:///c%3A/Users/Rayner/Project/MyApp” }

如果不先解码，就会得到类似 “c%3A” 的乱码方法，导致后续文件定位失败。

const rawFolder = wsJson.folder || "";const folder = decodeURIComponent);老实说，// 去掉 file:/// 前缀并解码

Pitfall	Solu tion
两个数据库先查工作区拿 ID，再查全局拿内容	分别打开 workspaceStorage/state.vscdb 与 globalStorage/state.vscdb，按流程关联查询
表名不一致	针对不同库使用对应表名进行 SELECT
Key 多段冒号。需要前缀匹配	使用 LIKE 'bubbleId:%‘ 并结合 SUBSTR/INSTR 提取 ID
Schema version _v 可变	解析时检查 _v 并在未知版本时仅打印 warning 不抛异常
空助手消息是流式中间态	过滤 text 为 "" 且 type 为 assistant 的记录
孤立对话需手动清理或导入	扫描全局 KV、过滤已知 composerIds、确认至少有一条非空文本后再导入
thinking 块结构不统一	同时检查 allThinkingBlocks.thinking、allThinkingBlocks.text 与根对象 thinking 字段
workspace.json 方法 URL 编码	去掉 file:/// 前缀后 decodeURIComponent 解码即可获得真实文件程序方法

接下来行动建议

• C​ursor 对话导入完整流程 —— 从 SQLite 中提取并重建完整会话结构。
• C​laude Code JSONL 中程序标签噪音过滤技巧 —— 差不多数据清洗思路可迁移。
• C​odex CLI / Trae / Copilot 等其他 AI 助手的数据源接入经验分享 —— 你的多源数据聚合能力。

再看项目地址，

---