Cursor与VS Code跨平台快捷键对照：三系统键位冲突与自定义指南

1. 为什么我同时用两套编辑器，还要专门做一张快捷键对照表

先交代一下背景。我平时主力开发环境是 macOS 笔记本，但公司配的台式机是 Windows，远程服务器清一色 Linux。三套系统、两个编辑器（Cursor 和 VS Code）来回切换，最折磨人的不是语法差异，而是快捷键。Cmd + Shift + P 在 Windows 上变成 Ctrl + Shift + P，这还算好记；真正坑人的是某些功能在 Cursor 里默认绑定的键位跟 VS Code 原版不一样，或者反过来——你以为两个软件共用一套底层，结果某个快捷键只有其中一个生效。

后来我干脆抽了半天时间，把 Cursor 和 VS Code 在 Windows / Linux / macOS 三套平台下的常用快捷键逐条过了一遍，做成一张对照表，打印出来贴在显示器旁边。用了一段时间后，又根据实际使用频率做了二次整理，砍掉了一些一年都用不到一次的冷门键位，补充了一批真正提高效率的组合键。这篇文章就是基于那张表的内容展开的，加上一些排查快捷键冲突和自定义绑定时的经验。

需要先说明的是，Cursor 本质上是 VS Code 的一个分支（fork），两者共享 Electron 壳子和大部分扩展生态，所以绝大多数快捷键是通用的。但 Cursor 额外塞进了 AI 相关的功能，比如对话面板、代码补全的接受/拒绝、行内编辑确认等，这些功能在 VS Code 里没有对应物，键位自然也不一样。反过来说，VS Code 有些老牌快捷键在 Cursor 里可能被 AI 功能占用了。搞清楚这两层关系，看下面的对照表才不容易懵。

这篇文章适合谁看？刚接触 Cursor 的 VS Code 老用户，或者准备从 VS Code 迁到 Cursor 的开发者，以及跟我一样在多系统之间来回切换、总记混键位的朋友。看完之后，你应该能回答这几个问题：

• 同样的操作，两个编辑器在三套系统上到底各按什么键
• 哪些快捷键换了编辑器就不一样了，需要额外记忆
• 遇到快捷键冲突时，怎么快速定位问题源头并修复

2. 通用编辑操作对照：三系统下的基础键位差异

2.1 文件、行操作与搜索

先看最基础的一层：文件打开、保存、关闭、查找替换。这类操作占了日常开发的大头，肌肉记忆最顽固，一旦换系统或者换编辑器，最容易按错。

表格里有一行值得单独拎出来提醒：重做的快捷键。很多从 Windows 迁到 macOS 的人会下意识按 Cmd + Y，但在 macOS 上 Cmd + Y 默认的功能是"重做"没错，可如果你装了一些插件，它也可能被抢走。VS Code 原版在 macOS 上默认是 Cmd + Shift + Z 做重做，Cmd + Y 也能用。Cursor 因为多了一层 AI 操作历史，偶尔会有奇怪的键位冲突，我见过不止一次用户反馈 Cursor 里 Cmd + Y 没反应，最后查出来是某个 AI 辅助插件的快捷键抢占。

另外注意一个细节：替换（Replace）在 macOS 上跟 Windows 不是简单换键位的关系。Windows 上替换是 Ctrl + H，但 macOS 上 VS Code 默认把 Cmd + Option + F 绑定给"编辑器内替换"，而不是 Cmd + H。Cmd + H 在 macOS 系统层面是"隐藏当前应用窗口"，几乎所有应用都认这个系统级快捷键，VS Code 和 Cursor 也没法拦截。所以如果你在 Mac 上按 Cmd + H 想找替换功能，结果窗口消失了，别慌——这是 macOS 的全局行为，不是编辑器出 bug。习惯之后反而觉得这个设计合理：替换这种高频操作在 Mac 上被安排到了 Cmd + Option + F，拇指按住 Command 的同时无名指按 Option，再够 F，姿势确实比 Cmd + Shift + F 顺手一些。

换行操作也要提一嘴：Windows / Linux 上在光标下方插入新行是 Ctrl + Enter，上方插入新行是 Ctrl + Shift + Enter；macOS 对应的是 Cmd + Enter 和 Cmd + Shift + Enter。这组键位在 VS Code 和 Cursor 里完全一致，不需要额外记。

2.2 多光标与文本选择

多光标是编辑器效率的分水岭。用鼠标点来点去改十处相同代码的，跟用多光标一次改完的，表面上看工作内容一样，实际耗时能差出好几倍。快捷键对比里，这一组是最值得背的。

这套键位在两个编辑器里基本一致，最大的坑反而在系统层面。Windows 上 Ctrl + Alt + ↑ 和显卡驱动（Intel、NVIDIA）的某些快捷键冲突，按下之后屏幕可能翻转，第一次遇到真的会吓一跳。解决办法是去显卡控制面板里把"启用图形快捷键"或"热键"关掉。macOS 上 Option + 鼠标点击在某些终端模拟器或远程桌面软件里可能被拦截，如果你是通过向日葵、ToDesk 这类工具连回办公室电脑写代码，多光标大概率失灵，这不是编辑器的问题。

还有个容易被忽略但极其重要的键位：Ctrl + U / Cmd + U，撤销上一个光标操作。多光标误操作时，比如不小心点了十处、或者选多了，常规 Ctrl + Z 会把前面的代码修改也撤掉，而 Cmd + U 只撤销光标相关的操作，保留代码内容。我见过很多用 VS Code 和 Cursor 三四年的开发者在多光标选错之后，只能退回去重新选一遍，就是不知道这个键。你在替换多行相同代码的时候，这个组合键能救命。

2.3 代码折叠与注释组

代码折叠在不同系统上的键位差异比较大，而且偏偏这功能在 Cursor 里表现跟 VS Code 略有出入。两个编辑器在刚打开大文件时默认折叠层级不同，我又经常需要快速收起整个函数体看概览，所以把这组也拎出来理一理。

注释和缩进这组则是跨平台最规则的，几乎不需要查表：

• 单行注释 / 取消注释：Windows 是 Ctrl + /，macOS 是 Cmd + /
• 块注释：Windows 是 Shift + Alt + A，macOS 是 Shift + Option + A
• 代码缩进：选中后按 Tab 向右、Shift + Tab 向左，三平台完全一致

折叠这组在 Cursor 里有一个已知的小差异：如果你在 AI 对话中要求 Cursor 对某段代码做了修改，修改后的区域折叠状态偶尔会异常重置，原本折叠的函数体会自动展开。这是 Cursor 的 AI edit 遗留状态，跟快捷键绑定本身无关，但容易让人误以为快捷键失灵。实际遇到时，重新折叠一次就好，如果频繁出现，建议检查是否有扩展在监听文档修改事件。

3. 调试与大文件跳转：最容易因平台切错键位的高频操作

3.1 调试快捷键对照

调试是另一个重灾区。我见过不少从 VS Code 迁到 Cursor 的人，按 F5 想启动调试却发现打开的是 AI 生成面板——等等，其实不是，Cursor 默认 F5 仍然是启动调试。但是 Cursor 的 AI 对话面板默认绑定是 Ctrl + L / Cmd + L，这个跟 VS Code 里"选中当前行"的快捷键冲突了。这是两套编辑器最大的键位分歧点，需要单独记忆。

先说结论：调试相关的 F 系列键，Cursor 没有改动 VS Code 的任何默认绑定，启动调试 F5、断点 F9、单步 F10/F11 全部一致。这一点对调试依赖肌肉记忆的人来说非常重要，意味着你不需要重新学一套调试键位。Cursor 主要在 AI 功能键位上动了手脚，而不是去碰调试键。

但 F 系列键有个物理层面的坑：在 macOS 上，默认情况下按 F5 触发的是"键盘亮度提高"或者打开 Mission Control 之类的系统功能，而不是调试启动——因为 MacBook 键盘顶部的 F1-F12 默认是功能键（调节亮度、音量等），你需要按住 Fn 键再按 F5 才能触发真正的 F5。除非你在"系统设置 -> 键盘"里勾选了"将 F1、F2 等键用作标准功能键"，在配对了机械键盘的情况下，这才不是个问题。

3.2 光标移动与大文件导航

这类操作在 VS Code 和 Cursor 里完全一致，因为 Cursor 没有改动这部分键位。但跨平台时有个天然差异：macOS 的外接键盘通常没有 Home / End / PageUp / PageDown 物理键，所以很多人觉得 macOS 上快速跳转效率低。其实 VS Code 和 Cursor 在 macOS 上默认绑定了 Cmd + ↑ / ↓ 跳到文件开头/结尾，Cmd + ← / → 跳行首/行尾，使用手感比 Home / End 更顺手。

如果是长年 Windows + Linux 双修的开发者，在 mac 上最容易犯的错是顺手按 Ctrl + ← 想按词跳转，结果发现只是把光标移动了一个字符，然后在代码里手忙脚乱。macOS 终端里 Ctrl + A 到行首、Ctrl + E 到行尾这组快捷键实际比 Cmd + ← / → 更值得形成肌肉记忆，因为它同时适用于终端命令行、对话框输入框和编辑器，无论你在 iTerm、VS Code 集成终端还是系统弹窗里，都能离手不离键盘完成行首行尾跳转。不过在普通文本框里，如果 App 不做特殊处理，Ctrl + A 通常会触发"全选"，所以这两套键位建议都记住。

另外，Vim 用户如果在两个编辑器里都开了 Vim 模拟器插件，那上面的 Cmd + ← / → 不一定生效——Vim 插件会拦截普通模式下的这些按键。如果你发现某些光标移动键在 Cursor 的 Vim 模式下失灵，去设置里搜 vim.handleKeys，看是不是被 Cursor 默认改了。

3.3 展开/收起侧边栏与面板

侧边栏控制和面板切换看起来不起眼，但对多文件、多终端并行的开发者来说，一天至少用几十次。按照"双手尽量不离开主键盘区"的原则，这组键位值得死记。

有一个很常见的疑问：VS Code 的"打开集成终端"快捷键 Ctrl + 中的反引号键，在 macOS 中文输入法状态下容易触发中文标点，导致终端面板半天开不出来。我个人的解决方法是额外绑定一个 Ctrl + J（在 Windows 上 Ctrl + J 也是切换终端面板的默认键之一）。macOS 上，如果你习惯用 Ctrl + J 做终端切换，可以去 Keyboard Shortcuts 里搜workbench.action.terminal.toggleTerminal，添加一个 ctrl+j` 键。

大文件的快速跳转，配合功能上 Cursor 往往默认收起了折叠状态，需要跳转时先展开再精确定位——所以折叠类的快捷键还是得记牢，这两类操作通常一起出现。

4. Cursor 专属 AI 键位：和 VS Code 的分水岭跟冲突源

4.1 Cursor 默认 AI 功能键位清单

Cursor 在 VS Code 上做 fork，不可能完全重做交互框架，所以它的增量核心在 Ctrl + L / Ctrl + K / Ctrl + I 等这套 AI 组合。这是两个编辑器之间最大的记忆负担来源，也是刚切到 Cursor 的人最崩溃的地方。

先挨个解释一遍。

Ctrl + L / Cmd + L 在 VS Code 里是"选中当前行"，这是很多老用户高频使用的键位。但 Cursor 把它改成了"打开 AI 对话面板"。这个改动直接导致一批 VS Code 老用户在 Cursor 里选中行的肌肉记忆失效。刚迁移时，我习惯性地选中一行代码，Ctrl + L，出来的不是选中，而是 AI 侧边栏——最初的几天我几乎每次都会被顶上火。

关于以上产品功能名称，需要注意版本差异：Cursor 的多个版本里对 AI 功能的叫法有过调整（比如 Composer 曾与 Agent、Chat 功能合并），不同版本下 Ctrl + L 打开的面板内容也不同。 如果你在用较新版本，Ctrl + L 打开的是统一对话界面；如果版本较老，可能只打开 Chat，Agent 功能需要另外的入口。建议升级到最新版，避免功能入口不一致导致的操作混乱。

Ctrl + K / Cmd + K 在 VS Code 里默认是"删除从光标到行尾的字符"（等价于 End + 删除，不过分成两步）。Cursor 拿它做行内编辑（Inline Edit）的唤起键。刚迁移用户按 Ctrl + K 想删行尾字符，结果弹出了 AI 编辑框，写了一半的代码差点被 AI 改掉。有几次我甚至没注意到弹了个框子，直接继续打字，代码就被自动改了，等看到 diff 才反应过来发生了啥。

不过 Ctrl + K 的冲突只存在于默认方案里：VS Code 其实把 Ctrl + K 留作 chord 前缀（即按了 Ctrl + K 后，继续按 Ctrl + S 是保存所有文件、Ctrl + [ 是折叠等），它本身并不执行删除，只是等待后续按键。Cursor 选择把它从 chord 前缀改成行内编辑唤起键，等于把所有以 Ctrl + K 开头的组合键都废掉了。如果你在 Cursor 里想用 Ctrl + K + Ctrl + D（跳到下一个错误）这类快捷操作，结果按了没反应，原因就在这。

4.2 最容易被忽略的隐藏差异：Tab 键与 Alt + ↑/↓

Tab 键的差异是最阴的。 在 VS Code 里，Tab 用于缩进、接受代码片段（Snippet）里的下一个占位符跳转、或者切换焦点，它并不会直接接受 AI 补全——VS Code 原版的 AI 补全接受键通常是 Tab 没错（GitHub Copilot 默认也是 Tab），但它的触发条件和 Cursor 不太一样。Cursor 更进一步，把 Tab 变成了"接受内联补全"的全局键，这导致一些常用功能和 Tab 关联失效。

举一个真实例子：我在 Cursor 里写 HTML，输入 div 后按 Tab 想快速生成代码片段（Emmet 展开），结果它直接接受了 Cursor 预测的下一行代码，把 Emmet 触发挤掉了。后来我去设置里把 editor.tabCompletion 打开，才是"Tab 补全当前词组"跟"Cursor 建议接受"共存的逻辑。如果你在 Cursor 里发现 Emmet、代码片段（Snippets）的 Tab 触发总失灵，优先检查 Cursor 设置里的 Tab 键行为（搜索 tab 或 inline suggest）。

Alt + ↑ / ↓ 的差异容易被忽略但影响很大。 在 VS Code 里，Alt + ↑ / ↓（macOS 是 Option + ↑ / ↓）默认是"向上/向下移动当前行或选中块"，这是调整代码顺序的高频操作。但在 Cursor 里，默认功能虽然保留了上下移动行，但在 AI 补全弹出时，Alt + ↑ / ↓ 被用来在补全建议之间切换。于是你在 Cursor 里按 Option + ↓ 想下移一行，如果此时刚好有 AI 建议候选显示，它不会下移代码行，而是在切换建议候选。

这两个功能的冲突在写代码时非常常见，尤其你刚写完一行、AI 马上又给出后续建议时，想用 Option + ↓ 调整前一行顺序，结果疯狂在切建议。排查方式：如果出现这种"按键没反应/反应不对"的情况，先看编辑区是否有灰色波浪线候选——有的话就是 AI 建议拦截了按键。 解决方法有两个：一是快速按两下 Esc 关掉建议，再执行行移动；二是去 Keyboard Shortcuts 里把 workbench.action.moveLinesDown（按 Shift + Alt + ↓ 可能有不同绑定）重新绑定一个组合键，避开与建议切换的冲突。

4.3 AI 补全的接受与拒绝

Cursor 的 AI 补全建议出现时，核心交互就是 Tab 接受、Esc 拒绝。但 Tab 牵扯太多其他功能，Esc 的问题也很多。在 VS Code 中 Esc 的职责是关闭弹窗、退出某种模式、清除选区，比较干净。Cursor 把 Esc 加了一层"关闭 AI 建议"的职责，如果建议驻留的时间窗口特别长，你按 Esc 想退出某个嵌套菜单，往往会先关掉建议，菜单还留在原地，得再按一次 Esc，操作节奏有点别扭。

某些场景下，按 Esc 拒绝建议时，如果建议已经被部分接受（灰色虚线的字符已经部分应用），那么 Esc 不会把整个建议回滚，只会关闭剩余部分。你要完整拒绝某段 AI 建议，更可靠的是 Ctrl + Z / Cmd + Z 撤销，建议会整体消失。这个差异文档里不会写，只有实际用多了才能感觉到。

还有一个我在实际使用中被坑过的点：补全建议和括号自动闭合的交互。Cursor 默认开启自动补全括号（Auto Surround），当你输入一个左括号时它可能自动插入右括号，同时 AI 建议又乘机在后面接上了错误的内容，按 Tab 接受后可能连右括号都是多余的。后来我把 editor.autoClosingBrackets 从 languageDefined 改成 never，减少 AI 建议与自动闭合的叠加出错，代码干净了不少。

4.4 Cursor 的代码选中与 AI 提问圈选

这是一个不太被注意但效率极高的 Cursor 专属操作：在 Cursor 新版本里，你不需要弹出 AI Chat 窗口，直接用鼠标选中一段代码，然后在选区下方会出现一个小工具条，包含"Ask AI"、"Edit"等操作。这个交互本身不依赖快捷键，但有一个隐藏快捷键选单：选中代码后，Ctrl + L / Cmd + L 会直接带着选中内容打开 AI 对话，省去鼠标点按工具条的步骤。

在 VS Code 里 Cmd + L 选中当前行但不会带出 AI；在 Cursor 里选中后 Ctrl + L 的语义就是"针对选区提问"。如果你要问的内容正好是一整行，操作路径可以是：光标停在该行任意位置 -> Cmd + L（选中整行）-> 再 Cmd + L（打开 AI 对话并捎带选中内容）。第一次按下 Cmd + L 时选中行、第二次按下时打开 AI——这算 Cursor 里一个连续的批量操作。

5. Cursor 里改快捷键的正确姿势：从冲突排查到自定义 keybindings

5.1 如何快速查看当前生效的快捷键

当你觉得某个快捷键"没反应"或"行为不对"，第一步不是去网上搜，而是直接查键位绑定。方法两个编辑器通用：

1. 按 Ctrl + Shift + P（macOS 为 Cmd + Shift + P）打开命令面板，输入 Preferences: Open Keyboard Shortcuts（也可以输入"keyboard"四个字母，面板会自动过滤出来）。
2. 在快捷键设置编辑器里，右上角有一个"记录按键"的小按钮（或者直接按你怀疑冲突的快捷键组合），系统会把当前绑定的命令显示出来。

注意：查快捷键时，最好每一步都检查两个层级——用户自定义的 keybindings.json 和默认值。如果某个组合键显示为多个命令绑定，VS Code 和 Cursor 会默认取后绑定的命令生效，另一个就静默失效了，不会弹出任何冲突提示。

在 Cursor 里，快捷键设置界面跟 VS Code 一样，在设置右上角有个 {} 图标（JSON 编辑器模式），点开后能看到用户级 keybindings.json；再点击左侧的"默认键盘快捷键"可以看全部默认绑定。建议只用 JSON 模式改键位，比图形界面更可控，方便 git 化备份。

5.2 keybindings.json 里如何给 Ctrl + Y 一个干净的"重做"

用 VS Code / Cursor 的 json 配置一个最典型的场景：macOS 上所有编辑器默认 Cmd + Shift + Z 做重做，但你已经习惯了 Cmd + Y，那么可以在 keybindings.json 里加一行：

json复制// macOS
{ "key": "cmd+y", "command": "redo" }

但注意：如果同时绑给了别的命令，会出现二义性。例如某些扩展把 Cmd + Y 绑到"删除整行"之类的操作，按顺序后绑定的可能覆盖前一个。想让某个键"绝对只干一件事"，可以设 "when" 条件来隔离上下文：

json复制{
  "key": "cmd+y",
  "command": "redo",
  "when": "editorTextFocus && !suggestWidgetVisible"
}

这个 when 条件的意思是"当焦点在编辑器文本里、且代码建议框没弹出时"才生效。用这种写法能够大大减少 Tab、Ctrl + L 这类键位跟 AI 建议的窗口期冲突。

5.3 自定义 Cursor AI 键位：避免改别的键引起连锁反应

Cursor 的 AI 相关快捷键在设置里已经被抽象成了独立的项，不再跟 VS Code 原生命令混在同一个 keybindings 列表里。你可以打开命令面板，输入 Cursor: Show All AI Features 或者直接在 Keyboard Shortcuts 里搜索 cursor，会看到类似这些命令：

如果你决定把 Ctrl + L 还给"选中当前行"，把 AI 对话改成 Ctrl + Alt + L，那么需要改两处：第一处在 keybindings.json 里把 cursor.chat.open 的键位改成 ctrl+alt+l；第二处是把 VS Code 原生命令 expandLineSelection（选中整行）重新绑回 ctrl+l。核心逻辑是别把 Cursor 的 AI 命令和 VS Code 的原生命令在没有任何隔离条件的情况下绑定到同一个键上，否则它们会互相覆盖，最后只活下来一个。

我在自己的配置里，最终方案是这样的：

• 保留 Ctrl + L 给 AI 对话（因为我觉得这个频率比选中整行高）
• 将"选中整行"改绑到 Ctrl + Shift + L（Windows）和 Cmd + Shift + L（macOS）——发现这跟"选择所有匹配项"冲突？没关系，我把后者改成 Ctrl + Alt + L，这样就分化开了。
• AI 对话保持在 Ctrl + L，选中整行用 Ctrl + Shift + L，行内编辑 Ctrl + K 不动，匹配选择用 Ctrl + Alt + L。

这套映射使用下来最顺手，基本没有互相打架的情况。

6. 实操经验：我从 Windows 切到 macOS 时的键位适应方案

6.1 修键前的必要认知：系统修饰键 + 编辑器键位是叠加关系

适应跨平台快捷键，最核心的认知是：编辑器不是运行在真空里，它受制于操作系统层级的按键拦截。macOS 里 Cmd 键承担了非常多系统动作，比如 Cmd + H 隐藏窗口、Cmd + M 最小化、Cmd + Q 退出程序；Windows 里 Win 键同样会抢占一堆组合。你可以在编辑器里绑定某个键，但系统全局如果先用掉了，编辑器收不到事件。

所以真正要做的不是"记一套编辑器快捷键"，而是"理解每个平台上哪些键被系统吃掉了，编辑器剩下的哪些键能自由使用"，再决定把功能映射到哪里。

拿三平台来比对：

实操层面，我会先在普通文本文件里按一遍想要用的组合，确认系统没有响应（比如没有弹搜索、没有切输入法、没有锁屏），再绑到编辑器命令上。

6.2 系统性训练方法：从"高级功能"倒推肌肉记忆

适应新键位最重要的一招：不要从抽象快捷键入手背，而要从高频场景倒推。

我最常做的几件事，按频率排序是：

1. 打开文件跳转（Ctrl + P / Cmd + P）
2. 打开命令面板（Ctrl + Shift + P / Cmd + Shift + P）
3. 当前文件内符号跳转（Ctrl + Shift + O / Cmd + Shift + O）
4. 按引用查找（Shift + F12 / F12）
5. 编辑器分屏（Ctrl + \ / Cmd + \）
6. 终端的开合（Ctrl + / Cmd +）

我看到很多"快捷键大全"，上来给你列两百个组合键，看完记不住，实际用不上。我的建议是只列自己一周内可能用到的，然后给这 6 个场景单独做一个"最小可用记忆表"贴在状态栏提醒区。先保证这 6 个场景在切换系统时不卡壳，后面低频操作再慢慢补。

等到第二个阶段，再去解决"在代码里跳来跳去"这类次高频场景，比如跳转定义（F12）、转到实现（Ctrl + F12 / Cmd + F12）、跳回上一个位置（Ctrl + - / Cmd + -）——这些对读开源代码特别重要。

6.3 Cursor + VS Code 混用时的键位同步策略

很多团队会同时使用 Cursor 和 VS Code——Cursor 做 AI 辅助和日常编码，VS Code 作为纯净环境做代码 Review、或者开大工程避免 AI 干扰部分代码。两个软件共享同一份用户配置？其实它们默认不同步。

默认情况下，VS Code 的 settings.json 和 keybindings.json 路径与 Cursor 是分开的：

• Windows：%APPDATA%\Code\User\（VS Code）和 %APPDATA%\Cursor\User\（Cursor）
• macOS：~/Library/Application Support/Code/User/ 和 ~/Library/Application Support/Cursor/User/

我采用的办法是：维护一份核心配置在 Git 仓库里，其中 keybindings.json 两边通用，靠同一份 JSON 同步，只单独在 Cursor 里加 AI 专属键位。需要注意，keybindings.json 里如果出现 Cursor 不认的 command（比如 cursor.chat.open 在 VS Code 里不存在），VS Code 会在加载时自动忽略，不会报错，所以全量复制过去并不可怕。反过来，VS Code 的某些扩展命令如果 Cursor 里没装那个扩展，也会被忽略。

这里有一个 git 化的好习惯：不要简单地把整个配置文件 cp 同步，而是维护两个分支，一个工作区里既有 keybindings.json 又有 cursor-keybindings.json。把 VS Code 与 Cursor 的差异隔离在两个文件里，之后升级系统、换机成本都会小很多。

7. 快捷键冲突排查思路：用二分法定位问题而非瞎猜

7.1 完整排查链路

遇到快捷键失灵，最忌讳的是打开设置乱改一气，或者去网上搜"XXXX快捷键不生效"。实际排查时，我用这套固定链路，基本能在五分钟内定位：

第一步：在编辑器里用命令面板手动执行这个功能，确认功能本身没坏。如果命令面板里都找不到这条命令，那说明可能是插件没启用、命令被藏起来了，而不是键位问题。

第二步：检查当前编辑器版本。Cursor 的版本迭代非常频繁，某些快捷键功能在版本升级后默认值会变。遇到键位"突然"失灵，先看是不是昨晚升级了。

第三步：打开 Keyboard Shortcuts，在搜索框输入这条命令名，看右侧绑定情况。如果有多条绑定，把多余的一条删掉或者改成其它键位，保留你想要的唯一绑定。

第四步：按"记录按键"按钮，实际按一遍目标组合键，看看编辑器收到的是什么。这一步能排除系统层和输入法层的干扰。比如 macOS 上微信的截图快捷键 Cmd + A、输入法的简繁切换快捷键有时会劫持编辑器按键，在编辑器里按记录之后，发现按键根本没出现在窗口里。

第五步：如果按键记录正常，但功能仍不触发，打开开发者工具（Help -> Toggle Developer Tools），在 Console 里执行 commands.executeCommand('目标命令ID')，直接看那条命令本身跑不跑得起来。如果命令本身报错，那就是扩展的问题。

这一步排查链路看似复杂，但熟练后只要滚动记忆四个关键词：功能可用 -> 键位绑定唯一 -> 系统没拦截 -> 命令无报错。

7.2 Cursor 和 VS Code 扩展各自抢键时的定位手段

很多冲突是扩展造成的。VS Code 和 Cursor 里任何一个扩展都可能在 package.json 里声明 contributes.keybindings，而且这些扩展的键位拥有相同的优先级，甚至默认情况下后启用扩展的键位会覆盖前面扩展的。

定位手段是把 Keyboard Shortcuts 编辑器里的输入过滤切换成 @ext:扩展名 来只看某个扩展贡献的键位。比如怀疑某个 AI 辅助类扩展抢了 Tab 键，就在这里输入 @ext:xxx 搜索，看一下它声明了哪些组合键，再手动删掉或改绑。

Cursor 因为内置了自己的 AI，如果你又装了第三方的 AI 扩展（比如 GitHub Copilot、通义灵码、Codeium 等等），两者同时监听 Tab、Ctrl + L 这类键，会出现补全建议打架的情况。我见过最夸张的一次，文件里同时出现 Cursor 的灰色建议和某个扩展的紫色建议，甚至还在互相叠加，造成显示错乱。那之后我把第三方 AI 辅助扩展全部卸载，只保留 Cursor 内置能力，键位冲突少了一大半。

7.3 系统级快捷键与编辑器键位冲突的检查清单

最后提炼一些容易忽略的系统级元凶，按系统列出清单，排查快捷键失灵时可以逐项对照：

Windows：

• 输入法：微软拼音、搜狗等默认的中英文切换（Shift / Ctrl + Space）在编辑器里可能拦截按键
• 显卡驱动：Intel 显卡的 Ctrl + Alt + 方向键会翻转屏幕；NVIDIA 的 Alt + Z 默认打开录屏
• 游戏模式/键盘驱动：如雷蛇、罗技的驱动设置里可能把某些 F 键定义为宏，接管了编辑器按键
• 截图工具：微信/QQ 的截图默认 Ctrl + Alt + A，跟编辑器多光标或全局搜索可能冲突

Linux：

• 桌面环境的窗口管理器：GNOME 的 Super 键通常被占用；KDE 的 Meta + 方向键会平铺窗口
• 输入法框架：ibus/fcitx5 在某些发行版里默认开着 Ctrl + Space 之类的切换键，如果你把 AI 补全的切换绑到 Ctrl + Space，会被输入法拦截
• 终端转义：通过 SSH 连远程开发时，某些按键在终端传输中会被吞掉（比如 Ctrl + Shift + F 可能被终端模拟器接管成全屏）

macOS：

• 输入法：系统自带中文输入法按 Shift 切换中英文，按 Caps Lock 切换大小写，还有可能拦截部分组合键
• 快捷键设置：系统设置 -> 键盘 -> 快捷键里，Spotlight（Cmd + Space）、输入法切换（Ctrl + Space）占用频率最高
• 窗口管理软件：Rectangle、Magnet 之类如果设置了 Cmd + Ctrl + 方向键做窗口分屏，编辑器的移动行（Option + ↑ ↓）虽然不至于冲突，但会同时触发系统分屏和编辑器移动，乱掉，需要留意
• 正在使用的远程控制软件：向日葵、ToDesk 的全屏模式会有自己的快捷键，可能截走 F 系列

8. 快捷键不是背出来的，是"用"出来的——我最后的几点体会

如果你只是想找一张对照表收藏起来，那看到这里其实已经可以去用了。但我想额外分享一点关于"记快捷键"的方法论，因为它对我的实际效率提升比其他技巧都大：

不要逼自己一天内记住所有快捷键。 我经历过两个阶段。第一阶段是刚用 VS Code 时，去网上找了张几百行的"快捷键大全"，打印出来贴在桌上，结果真正常用的不超过20个，其余绝大多数在半年内都没看过一眼。等到用 Cursor，就转换思路，只记那些比鼠标操作"快一倍以上"的操作，比如命令面板、文件跳转、多光标、折叠、分屏、调试的 F 系列——这些是真正能提升节奏感的操作，值得形成肌肉记忆。至于那些"打开某个侧边栏的一级子项"之类的低频键，真到用的时候鼠标点一下，一点都不丢人。

第二阶段是跨平台之后，我意识到"快捷键记忆"跟"操作频率"强相关，而跟"快捷键列表"本身没关系。每次切系统后的前两周，我只使用一张极小的备忘卡，上面有十来个最关键的组合键，凡是碰到"这功能要翻菜单找"的时候就去翻平时整理好的图谱，几次下来这套键位自然就记牢了。不要尝试在切换系统后的第一天就达到全速，给大脑一个适应期，这跟学会游泳、弹琴的逻辑一致。

如果你问我现在更依赖哪套组合键，我的回答反而有些反直觉：在 Cursor 里，最常按的其实不是各种 AI 组合键，而是 Ctrl + Shift + P / Cmd + Shift + P 打开命令面板，然后在里面通过文字命令触发所有操作——包括 AI 对话、行内编辑、启停调试、切换终端。我把命令面板当成编辑器的"中文搜索引擎"来用。命令面板会随着年龄增长和使用版本更新不断完善，它是两个编辑器共有的、受 AI 影响的版本差异最小的入口。

建议你也做一件事：现在打开 Cursor 或 VS Code，把命令面板按出来，然后依次执行 Preferences: Open Keyboard Shortcuts，在搜索框输入你平时用鼠标点的频率最高的10个动作，看看它们各自绑定的是什么键位，足够用了才需要去找那些真正提升效率的进阶键位。

全文的对照表是为了让你在换系统/换编辑器的时候少骂几句，但真正干活的时候，请只相信自己的肌肉记忆加上随时可查的命令面板——这是我在两把机械轴、两套系统、两个编辑器之间来回切换之后，最想跟你分享的一句话。