你花一小时在笔记本上把 Cursor 调得很顺手：.cursor/rules 精修过、加了两个 MCP server、Cmd+L 重新绑定。第二天打开台式机，你昨晚加的规则没了。或者更糟：晚上再回到笔记本，台式机昨天那份旧配置反过来把你刚做的全覆盖了。
首先要知道一件事（截至 2026 年 6 月）：Cursor 没有原生的 “Settings Sync” 功能。和 VS Code 不一样，Cursor 里既没有 Settings Sync: Turn On 命令，也没有按类别同步的 UI。所以如果你的配置真的在两台机器之间流动，那一定是别的层在干这件事：第三方 Gist 同步插件、dotfiles 软链接、被云盘同步的文件夹（iCloud/Dropbox/OneDrive）、“Import from VS Code” 按钮，或者 Profiles 的导出/导入。这些机制全是后写覆盖，“赢家”是最近一次写入的那台机器，而不是带着你想要修改的那台。
最快的修复路径：现在立刻停掉每一层同步，挑出带着你想要配置的那台机器，先对它的 Cursor 配置目录做一份文件级备份，然后再把这份状态往外推。下面按从轻到重排。
第一步：到底是哪一层同步在搬你的配置？
Cursor 自己不同步。动手之前先认清机制，否则你会跟错误的对象较劲。
| 同步层 | 判断特征 | 在哪里 |
|---|---|---|
| Gist 同步插件（如 “Sync Everything”、“cursor-settings-sync”） | 装了一个带 GitHub token 的插件；命令面板里有 “upload/download settings” 命令 | 插件的状态栏图标，或 Cmd+Shift+P 输入 “sync” |
dotfiles + 软链接（stow/ln -s） | settings.json 是软链接，不是真实文件 | ls -l "~/Library/Application Support/Cursor/User/settings.json" 显示箭头 -> |
| 被云盘同步的文件夹 | 整个 Cursor 配置目录在 iCloud Drive / Dropbox / OneDrive 里 | 把配置目录路径和你的云盘挂载点对一下 |
| ”Import from VS Code” | 你最近点过它，VS Code 的配置盖到了 Cursor 上 | Cursor Settings -> General -> Account -> “VS Code Import” |
| Profiles 导出/导入 | 你在一台导出 .code-profile / Gist 又在另一台导入 | Cmd+Shift+P -> Preferences: Open Profiles (UI) |
| 根本不是同步（git 状态） | 只有 .cursor/rules 或工作区 mcp.json 不一样 | 项目里 git status 显示有未提交修改 |
如果以上都对不上，那就是你两台机器各有一份独立配置、根本没人同步。这正是最常见的”惊讶点”：大家以为 Cursor 会像 VS Code 那样自动同步，其实并不会，那份”丢失”的配置从来没被上传到任何地方。
Cursor 把你关心的文件放在哪
恢复过程中你会反复用到这些路径。（截至 2026 年 6 月。）
| 内容 | macOS | Windows | Linux |
|---|---|---|---|
| 用户配置目录 | ~/Library/Application Support/Cursor/User/ | %APPDATA%\Cursor\User\ | ~/.config/Cursor/User/ |
settings.json | .../User/settings.json | %APPDATA%\Cursor\User\settings.json | ~/.config/Cursor/User/settings.json |
keybindings.json | .../User/keybindings.json | %APPDATA%\Cursor\User\keybindings.json | ~/.config/Cursor/User/keybindings.json |
| 代码片段 snippets | .../User/snippets/ | %APPDATA%\Cursor\User\snippets\ | ~/.config/Cursor/User/snippets/ |
| 全局 MCP server | ~/.cursor/mcp.json | %USERPROFILE%\.cursor\mcp.json | ~/.cursor/mcp.json |
| 项目级 MCP | <project>/.cursor/mcp.json | <project>\.cursor\mcp.json | <project>/.cursor/mcp.json |
| 项目规则 | <project>/.cursor/rules/ | <project>\.cursor\rules\ | <project>/.cursor/rules/ |
注意：Cursor 里很多通过 UI 开关切换的设置并不在 settings.json 里，而是存在一个 SQLite blob：.../User/globalStorage/state.vscdb。这个数据库正是云盘同步最常搞坏的东西——两台机器写同一个 state.vscdb，要么后写覆盖，要么文件写到一半变成损坏文件。
常见原因
按”第二台机器覆盖了我的配置”这一情形的发生频率排序。
1. Gist 同步插件推了过时状态（后写覆盖）
这类插件不是合并引擎。机器 B 一打开，插件自动下载了旧 Gist（或者把 B 的过时状态自动上传、盖掉了你那份好 Gist），笔记本上的修改就丢了。
如何判断：打开插件的输出/日志频道，或它的命令（Cmd+Shift+P 输入 “sync”）。最后一次上传的时间戳和来源机器一目了然。如果 Gist 最后一次提交来自不该来的那台机器，那就是覆盖点。
2. 云盘同步把 state.vscdb 搞坏或覆盖了
如果你的 Cursor 配置目录在 iCloud Drive、Dropbox 或 OneDrive 里，两台机器会争抢同一个 state.vscdb。这是最糟的情况，因为它是二进制文件，同步到一半不只是被覆盖，还可能直接损坏。
如何判断：配置目录路径里包含某个云盘挂载点，或云盘客户端生成了冲突副本，比如 state (machine-B's conflicted copy).vscdb。
3. dotfiles 的扩展列表对账卸掉了扩展
dotfiles 套路会把 cursor --list-extensions 的输出存进一个文件，然后在另一台机器上装上列表里有的、卸掉列表里没有的。如果列表是过时的，它会悄悄把你新装的扩展删掉。
如何判断：你的同步脚本会对比一个被追踪的 extensions.txt 并执行 cursor --uninstall-extension。同步跑完后，你手动装的扩展消失了。
4. .cursor/rules 是工作区级的，本来就不该被同步
.cursor/rules 在工作区目录里，不在用户配置目录。你把仓库克隆到两台机器、其中一台改了规则但没提交，另一台就永远看不到。看上去像同步失败，其实是 git 状态问题。
如何判断：机器 A 上项目里 git status 显示 .cursor/rules 有未提交修改；机器 B 是上一次提交的版本。
5. MCP server 配置过去了，但二进制没跟着
当 ~/.cursor/mcp.json（或工作区 .cursor/mcp.json）被同步/复制时，真正的 mcp-server-foo 可执行文件并不会跟着走。机器 B 收到一个指向不存在二进制的配置。
如何判断：机器 B 看得到 MCP 条目，但启动失败、报 command not found（或者在 Cursor Settings -> MCP 里一直是黄/红状态）。可参考 Cursor MCP server 连不上。
6. “Import from VS Code” 覆盖了 Cursor 配置
Cursor Settings -> General -> Account -> “VS Code Import” 会把 VS Code 的 Extensions、Themes、Settings、Keybindings 盖到 Cursor 上。如果你已经定制过 Cursor 再去点它，就可能把 Cursor 专属的调整覆盖掉。
如何判断：你的快捷键/主题突然变回了以前 VS Code 的样子；你记得自己最近点过 Import。
7. 两台机器 Cursor 版本不同，对同一字段解读不同
新版本里新增的字段，旧版本可能完全不认；旧版本写回配置时还可能把它去掉。
如何判断：两台机器都显示有这个字段，但在其中一台没有任何效果。Cursor -> About（或 cursor --version）里版本号不同。
开始之前
- 在决定保留哪一份之前，两台机器都不要再继续改配置。
- 在每台机器上记下你”上一次想保留的修改”的时间点。
- 弄清楚丢失的数据在用户配置目录、SQLite
state.vscdb、工作区.cursor/、还是别的地方。 - 动任何东西之前，先把你信任的那台机器的整个 Cursor 配置目录（路径见上表）手动备份一份。
需要收集的信息
- 当前是哪一层在同步（用上面的判断表）。
- Gist 同步插件的话：它最后一次上传/下载的时间戳和来源机器。
- 每一层各自动了哪些类别/文件。
- 两台机器的
cursor --version。 - 出问题的文件副本：
settings.json、keybindings.json、snippets/、~/.cursor/mcp.json、.cursor/rules/*。 - 每台机器的登录身份 / Gist 账号。一台用个人 Gist 账号、另一台用别的账号，会把状态切成两份独立存储。
分步修复
按从最便宜到最彻底排。
第 1 步：确定基准机器，冻结每一层同步
挑出带着你想要配置的那台机器。然后在每一台机器上，把正在搬配置的东西停掉：
- Gist 同步插件：关掉它的自动上传/自动下载（或直接禁用插件），让它别再推。
- 云盘文件夹：暂停云盘客户端，或者干脆把 Cursor 配置目录从被同步的位置挪出来（这是更好的长期修复，见第 5 步）。
- dotfiles：在基准状态定下来之前别跑同步脚本。
基准状态恢复完之前，任何一层都不该往别的机器写配置。
第 2 步：把基准状态显式备份一份
在基准机器上，复制整个配置目录（这样能一并抓到 settings.json、keybindings.json、snippets/ 和 state.vscdb blob）：
cp -R "$HOME/Library/Application Support/Cursor/User" "$HOME/Cursor-User.backup-$(date +%Y%m%d-%H%M%S)"
cp -R "$HOME/.cursor" "$HOME/.cursor.backup-$(date +%Y%m%d-%H%M%S)"Windows PowerShell：
Copy-Item -Recurse "$env:APPDATA\Cursor\User" "$env:APPDATA\Cursor\User.backup"
Copy-Item -Recurse "$env:USERPROFILE\.cursor" "$env:USERPROFILE\.cursor.backup"这是你的保险。万一后续同步又出事，从这里恢复。
第 3 步：让基准状态成为权威版本
怎么”推”取决于是哪一层：
-
Gist 同步插件：在基准机器上强制上传到 Gist（插件的 “upload settings” 命令）。这会用你那份好状态替换远端 Gist。确认 Gist 的新提交时间戳。
-
dotfiles：提交基准机器的文件（包含一份最新的
cursor --list-extensions导出）并推送：cursor --list-extensions > extensions.txt git add settings.json keybindings.json snippets extensions.txt git commit -m "chore: pin canonical Cursor config" git push -
云盘文件夹：不用推；你会在第 5 步把这一层去掉。确保基准机器的文件完好即可。
第 4 步：把基准状态拉到其它机器，一次一台
在每台非基准机器上，关闭 Cursor：
-
Gist 同步插件：跑它的 “download settings” 命令，用权威 Gist 覆盖本地。
-
dotfiles：
git pull，重新建链接（stow --no-folding -t ~ *或你的ln -s），然后对账扩展：cursor --list-extensions > current.txt comm -13 <(sort current.txt) <(sort extensions.txt) | xargs -I\{\} cursor --install-extension \{\} -
手动：把
settings.json、keybindings.json、snippets/、~/.cursor/mcp.json从备份复制覆盖本地文件。
重新打开 Cursor，确认它和基准机器一致，然后再处理下一台。不要几台一起搞。
第 5 步：把配置从任何”争抢二进制”的同步层里挪出来
无声覆盖最大的元凶，就是两台机器写同一个二进制 state.vscdb（云盘文件夹），或者扩展列表互相赛跑。把边界修对：
- 绝对不要把 Cursor 配置目录放在 iCloud/Dropbox/OneDrive 里。如果已经放了，挪出来，让 Cursor 从你的备份重新生成。
- 优先用文本文件同步（把
settings.json+keybindings.json放进 Gist），而不是整目录同步——文本文件能扛过半截同步，而且合并冲突看得见。 - 把 Gist 同步插件设成手动上传/下载，而不是自动，这样两台机器永远不会赛跑。
第 6 步：工作区级配置改用 git 管理（而不是同步）
.cursor/rules、工作区 .cursor/mcp.json、.vscode/settings.json、.vscode/extensions.json 应该进项目仓库，而不是进任何配置同步层：
git add .cursor .vscode
git commit -m "chore: pin workspace config"
git push之后第二台机器靠 git pull 拿到这些，这才是合理的边界。这一步也把它们彻底移出了被覆盖的范围。
如何确认修好了
- 在机器 A 改一个无害的设置（如字体大小），跑你的推送步骤，在机器 B 拉取：B 跟上了，而且只有它跟。
- 在机器 A 改
.cursor/rules：它应该只通过git pull出现在机器 B，绝不走配置同步层。 - 两台机器上
cursor --list-extensions返回相同的扩展集合。 Cursor Settings->MCP在每台机器上都显示 server 为绿色（不绿就看 Cursor MCP server 连不上）。- 配置目录里任何地方都没有冲突副本文件（如
state (...'s conflicted copy).vscdb）。
长期预防
- 记住 Cursor 没有原生同步。只选一种同步机制，在每台机器上都用它。混用两种（既装 Gist 插件又用云盘文件夹）必然赛跑。
- 让 Cursor 配置目录远离任何被云盘同步的文件夹。同步文本文件，别同步整目录或
state.vscdb。 .cursor/rules、.vscode/、项目级.cursor/mcp.json都进 git。- 几台机器的 Cursor 版本尽量对齐（至少同一个 minor），免得新设置被旧版本去掉。
- 把
cursor --list-extensions的输出纳入 git，这样扩展漂移看得见、可复现。 - 所有机器都用同一个 Gist 账号 / 登录身份。混用账号会把状态切成两份独立存储。
常见误区
- 指望 Cursor 的
Cmd+Shift+P里有Settings Sync: Turn On命令。没有。那是 VS Code 的功能，Cursor 没有做。 - 把 Cursor 配置目录放进 iCloud/Dropbox/OneDrive，以为它会”自动同步”。它会在二进制
state.vscdb上赛跑，甚至把文件搞坏。 - 已经定制过 Cursor 之后才去跑 “Import from VS Code”。它会覆盖 Cursor 专属的设置和快捷键。
- 任何自动同步开着的时候在两台机器上改配置。谁后写谁赢，另一台被默默吃掉。
- 把 API key 放进会被同步的
settings.json。它会出现在每台机器上和 Gist/云盘存储里。用环境变量或本机独立的 secret 文件。 - 以为
.cursor/rules会被同步只因为别的配置会。它是工作区级的，只通过 git 移动。 - 恢复备份时只复制
settings.json，忘了keybindings.json、snippets/、~/.cursor/mcp.json和state.vscdbblob。
常见问题
Q：Cursor 里 Settings Sync: Turn On 命令在哪？
没有这个命令。截至 2026 年 6 月，Cursor 没有内置 Settings Sync。如果你的配置在机器之间流动，那是第三方插件、dotfiles、云盘文件夹或某次导入干的。用本文开头的表来判断是哪一种。
Q：我的同步写着”已合并”，但机器 B 的快捷键就是错的。
Cursor 的任何同步层都不会对 keybindings.json 做真正的合并，都是后写覆盖。确认基准机器，把它的 keybindings.json 推上去（第 3、4 步）。
Q：MCP 条目过去了，但 server 启动报 “command not found”。
机器 B 上没装对应二进制。~/.cursor/mcp.json 里的配置过去了，可执行文件没过去。在新机器上跑你的 MCP 安装步骤。参考 Cursor MCP server 连不上。
Q：能不能回滚到被覆盖之前的配置？
没有同步历史 UI。第 2 步生成的 Cursor-User.backup-* 和 .cursor.backup-* 目录就是你的回滚点。关掉 Cursor，恢复目录，再打开。
Q：把 Cursor 文件夹放进 iCloud/Dropbox 是不是个好的同步办法？
不是。整个配置目录是最不该云盘同步的东西，因为 state.vscdb 是二进制文件，两台机器会互相覆盖或把它搞坏。改成把 settings.json 和 keybindings.json 当文本同步，或者用设为手动的 Gist 插件。
Q：这些办法能跨个人账号和工作账号用吗？
只有当两台机器指向同一个 Gist/账号才行。个人 GitHub 账号上的 Gist 和工作账号上的 Gist 是两份独立存储，配置不会互相流动。