esc不退出插入模式的根本原因是输入链中断，非插件故障；需检查状态栏变化、用ctrl+[临时替代，或配置vim.usectrlkeys和vim.handlekeys修复。
VSCode 安装 Vim 插件后为什么 Esc 不退出插入模式？
根本原因是插件默认启用「模拟 Vim 的非递归映射」，但部分键盘布局或远程桌面会吞掉 Esc 事件，尤其 macOS 的 Caps Lock 改键、Windows 远程桌面、或某些机械键盘固件。不是插件坏了，是输入链断了。
- 先检查是否真没触发：在插入模式下按
Esc，看右下角状态栏是否从-- INSERT --变成-- NORMAL -- - 若无反应，临时用
Ctrl+[替代 —— 它和Esc在 Vim 协议里等价，且更可靠 - 长期方案：在 VSCode 设置里搜
vim.useCtrlKeys，设为true；再打开vim.handleKeys，把{"<c->": false}</c->改成{"<c->": true}</c->，避免被 VSCode 原生快捷键劫持
如何让 jj 或 jk 真正退出插入模式？
Vim 插件默认不绑定这些组合键，必须手动加到 vim.insertModeKeyBindings，而且顺序和冲突逻辑很关键：它只匹配「连续、无间隔、无其他按键干扰」的输入流。
- 在设置 JSON 中添加：
"vim.insertModeKeyBindings": [ { "before": ["j", "k"], "after": ["<esc>"] } ]</esc> - 别写成
"before": ["j", "j"]后又加另一条jk—— 插件会按数组顺序匹配，前者会吃掉所有jj，但后续的j按下（比如想输jj字符）就永远触发不了 - 如果同时用了中文输入法，
jk在中文状态下不会触发 —— 这是输入法层拦截，不是插件问题；建议退出插入模式后再切输入法
vim.normalModeKeyBindingsNonRecursive 和 recursive 有什么实际区别？
非递归绑定（NonRecursive）执行完就停，不重新解析结果；递归绑定会把输出当新输入再走一遍映射 —— 这决定了你能不能用映射“造快捷键”。
- 比如想用
leader + s保存并退出："vim.normalModeKeyBindingsNonRecursive": [ { "before": ["<leader>", "s"], "commands": ["workbench.action.files.save", "workbench.action.closeActiveEditor"] } ]</leader>这里必须用NonRecursive，否则save命令返回的响应可能被误识别为按键流，引发意外跳转 - 但如果你想实现「按
gl跳到上次修改位置」，就得用recursive绑定：gl→`→'→ 最终触发跳转，中间每步都需再次解析 - 性能上，
recursive有微小延迟，高频操作（如hjkl移动）绝不能放这儿
终端内嵌 Vim 模式（如 Git commit 编辑器）为何不响应 VSCode 的 Vim 映射？
因为那是 Git 调用的系统级 vim 或 vi，完全绕过 VSCode 插件。VSCode 的 Vim 模式只作用于编辑器主窗口的文本区域，不注入终端进程。
- 验证方法：在终端里运行
git config --global core.editor "code --wait"，这样 commit 会弹出独立窗口，此时才受 VSCode Vim 插件控制 - 若坚持用终端内编辑，只能配置系统 vimrc：
~/.vimrc加set timeoutlen=500防止jk等组合键超时中断 - 注意 Windows 上 Git Bash 默认用
vi而非vim，功能受限；可改用vim -u NONE启动，再加载你的映射
Vim 模式真正的复杂点不在配置本身，而在于它横跨三层：键盘输入层（硬件/OS/输入法）、VSCode 事件层（插件拦截时机）、以及终端/外部命令层（完全不可控）。调一个 jk 退出，可能要同时动三处，且任何一层静默失败都不会报错。
