Esc无反应是因VSCode默认劫持Esc绑定命令面板，需在快捷键设置中删除冲突项并确保vim.useCtrlKeys为true；y/p不同步系统剪贴板需启用vim.useSystemClipboard；jj退出插入模式须配置vim.insertModeKeyBindings。
VSCode 装了 Vim 插件却用不起来，不是插件有问题，而是默认配置和原生快捷键冲突太常见——尤其是 Esc 按下没反应、y/p 粘贴不到系统剪贴板、jj 退出插入模式失灵，这三类问题占了实际使用障碍的 80% 以上。
Esc 键按了没反应？先查快捷键劫持
VSCode 默认把 Esc 绑给了命令面板（workbench.action.showCommands）或终端切换（workbench.action.terminal.toggleTerminal），直接拦截了 Vim 插件监听。这不是插件没装好，是 VSCode 抢先吃了按键。
- 打开快捷键设置：
Cmd+K Cmd+S（macOS）或Ctrl+K Ctrl+S（Windows/Linux） - 搜索
escape，找到对应命令条目，右键 →「删除键绑定」 - 确认设置里
vim.useCtrlKeys是true（新版默认开启，但远程开发环境或旧配置可能关着） - 重启 VSCode 或执行
Cmd+Shift+P→Developer: Reload Window
yank/paste 不同步系统剪贴板？改 clipboard 配置
VSCode Vim 默认用内部寄存器（" 开头），yy 复制的内容不会进系统剪贴板，Ctrl+V 也粘贴不出外部复制的文本——这是行为差异，不是 bug。
- 在用户级
~/.vimrc中加一行：set clipboard=unnamedplus（Linux/macOS）或set clipboard=unnamed（Windows） - VSCode 设置中开启
vim.vimrc.enable（设为true） - 或者更直接：在
settings.json里加"vim.useSystemClipboard": true - 注意：macOS 上需确保 VSCode 有「辅助功能」权限，否则
unnamedplus无效
想用 jj 或 jk 退出插入模式？必须走 JSON 映射
Vim 原生不支持双键退出，但 VSCode-Vim 插件通过 vim.insertModeKeyBindings 实现了这个能力。它不是普通快捷键，而是插入模式下的按键序列监听，所以不能用 keybindings.json 里的常规方式配。
- 打开
settings.json（Cmd+, → {}图标） - 添加配置：
"vim.insertModeKeyBindings": [ { "before": ["j", "j"], "after": ["<Esc>"] }, { "before": ["j", "k"], "after": ["<Esc>"] } ] -
before必须是小写字母数组，顺序敏感；after中的<Esc>必须带尖括号和英文符号 - 副作用：如果你常写
jj（比如 Python 注释里写# jj），会有约 200ms 的输入延迟等待第二击
为什么 i 不跳到行首？大小写决定行为
很多人以为 i 应该像 IDE 那样默认跳到行首，其实不是：i 就是在光标当前位置前插入，I 才是跳到行首非空字符前。这个区别被大量新手忽略，导致反复按 i 却卡在奇怪位置。
-
i：光标前插入（等价于原生 Vim 的i） -
I：移动到当前行第一个非空白字符前插入（等价于原生 Vim 的I） -
a：光标后插入（a） -
A：移动到行尾插入（A） - 如果习惯点哪输哪，就用
i；如果想批量在行首/行尾加内容，记得切大小写
真正卡住人的从来不是 Vim 操作本身，而是 VSCode 和插件之间那几处默认不一致的“隐性约定”——比如 Esc 被劫持、剪贴板隔离、插入模式退出延迟、大小写行为差异。这些点不手动调，光靠装插件永远只是半残状态。
