Esc 键无法退出插入模式的根本原因是 VSCode 默认将 Esc 绑定至命令面板或终端切换，劫持了 Vim 插件监听；需在快捷键设置中删除冲突绑定，并确保 vim.useCtrlKeys 为 true。
VSCode 安装 vim 插件后为什么 Esc 按不退出插入模式？
这是最常遇到的“卡住”现象：敲完代码按 Esc，光标没反应，依然在插入状态。根本原因不是插件没装好，而是 VSCode 默认把 Esc 绑给了命令面板快捷键（Ctrl+Shift+P 的呼出逻辑），直接劫持了 Vim 插件对 Esc 的监听。
解决方法是手动禁用冲突绑定：
- 打开快捷键设置：
Ctrl+K Ctrl+S（Windows/Linux）或Cmd+K Cmd+S（macOS） - 搜索
escape - 找到命令为
workbench.action.terminal.toggleTerminal或workbench.action.showCommands的条目，右键选择「删除键绑定」 - 确保
vim.useCtrlKeys在设置中为true（默认开启，但某些旧版本或远程环境可能关闭）
如何让 jj 或 jk 代替 Esc 退出插入模式？
Vim 原生不支持双键映射退出插入模式，但 VSCode 的 Vim 插件通过 vim.insertModeKeyBindings 提供了这个能力。它本质是监听插入模式下的按键序列，触发退出动作，而不是传统意义上的“按键绑定”。
配置方式（在 VSCode 设置 JSON 中添加）：
"vim.insertModeKeyBindings": [
{
"before": ["j", "j"],
"after": ["<esc>"]
},
{
"before": ["j", "k"],
"after": ["<esc>"]
}
]
</esc></esc>
注意点：
-
before是数组形式，每个元素是一个按键，顺序敏感；j和k必须小写 -
after中的Esc或escape - 该配置只在插入模式生效，不影响正常编辑；但若你常用
jj输入文字（比如写 Python 注释），会有轻微延迟响应
vim.normalModeKeyBindingsNonRecursive 和 vim.normalModeKeyBindings 有什么区别？
两者都用于普通模式下自定义快捷键，但递归性差异直接影响行为稳定性和调试难度。
vim.normalModeKeyBindings 是递归绑定：比如你把 leader+w 映射为 :w，而 :w 又触发了其他映射，就会继续展开——容易引发无限循环或意料外跳转。
vim.normalModeKeyBindingsNonRecursive 是非递归绑定：映射结果就是最终动作，不二次解析。日常自定义推荐用它，尤其涉及命令行模式（:）或外部命令时。
- 想快速保存并跳到下一个错误？用非递归：
"vim.normalModeKeyBindingsNonRecursive": [ { "before": ["<leader>", "s"], "commands": [":w<cr>:lopen<cr>"] } ]</cr></cr></leader> - 避免把
,后又误配,w导致和原生w（跳词）冲突 - 如果用了递归绑定又出问题，先检查是否某条映射意外触发了另一条——这类问题很难一眼定位
为什么在远程开发（SSH/WSL）里 Vim 插件响应变慢或部分按键失灵？
这不是插件本身的问题，而是 VSCode 远程通道对键盘事件的采样和转发有延迟，尤其在高延迟网络或资源受限的远程机器上，Esc、Ctrl+[ 这类短促按键最容易被丢弃或合并。
实操建议：
- 优先用
Ctrl+[替代Esc：它更可靠，且多数终端模拟器原生支持 - 关闭远程端的
vim.useSystemClipboard（设为false），避免剪贴板同步拖慢按键流 - 禁用远程工作区里不必要的插件，特别是那些监听全局按键的（如某些 Snippet 扩展）
- 如果使用 WSL，确认 Windows 端没有启用“粘滞键”或第三方键盘管理工具（如 AutoHotkey、Karabiner）干扰底层事件
真正难调的，是那种按了 dd 却只删了一行、或者 ci" 进入修改字符串后退不出去的情况——这时候别急着改配置，先 Ctrl+Shift+P >「Developer: Toggle Developer Tools」看 Console 有没有 Vim: failed to parse motion 类报错，往往说明某个按键序列被截断或解析异常。
