VSCode快捷键效率取决于理解光标行为与上下文：Ctrl+D逐次扩展选中、Shift+Alt+I在行末插光标需先选行、Ctrl+Shift+L受只读区域限制、Alt+Click为瞬时操作，所有行为均受文件类型、折叠、插件等上下文影响。
VSCode 里“快捷输入”不是靠背快捷键列表练出来的，而是靠理解光标行为、选择逻辑和编辑上下文——用错场景，再熟的快捷键也卡顿。
Ctrl + D 多次按为什么只选中两个词？
这是最常被误读的快捷键。它不“自动选中全部匹配项”，而是按顺序逐个扩展选中：第一次选中光标所在词，第二次选中下一个相同词，第三次再下一个……直到没匹配为止。
- 如果光标不在单词上（比如停在空格或符号后），
Ctrl + D会先尝试选中当前行，行为突变 - 选中范围被手动扩大过（比如拖选了一部分），
Ctrl + D会基于该范围做子串匹配，而非全词匹配 - 文件太大或含大量正则特殊字符（如
{、/）时，匹配引擎可能提前终止，看起来像“漏选”
Shift + Alt + I 怎么在每行末尾加逗号？
这个操作本质是“在每行末尾插入光标”，不是“加内容”。内容得你手动输——它只是把光标批量摆到位。
- 必须先选中目标行块（比如
Ctrl + G跳到第10行，Shift + ↓拉到第20行）；否则默认作用于整个文档 - 如果某行是空行，
Shift + Alt + I会把光标插在行首，不是行尾——因为空行没有“行尾”可锚定 - 输完逗号后，别急着按
Esc：按一次只退出最后一个光标，其他光标还在；要彻底退出多光标模式，得按两次Esc或点一下编辑器任意空白处
Ctrl + Shift + L 一次性选中所有匹配项，但改完只生效一部分？
这通常不是快捷键失效，而是 VSCode 的“编辑保护机制”在起作用：当某匹配项处于不可编辑区域（如字符串内、注释中、被 readonly 修饰的变量名），它会被自动排除在可编辑光标之外。
- 检查状态栏右下角语言模式——如果是
JSON，双引号内的字段名不会被Ctrl + Shift + L选中；换成Plain Text就能全选 - 某些插件（如 Prettier、ESLint）会临时锁定部分文本区域，禁用直接编辑；关掉插件或临时禁用格式化可验证
- 选中后若看到部分光标呈灰色半透明态，说明它们已被标记为“只读”，无法输入
Alt + Click 插入多个光标，但鼠标移开就消失了？
这是正常设计：Alt + Click 是“瞬时插入”，不是“持久锚点”。光标只在你点击的那一刻存在，后续移动鼠标或按键都会触发编辑行为，而不是维持多光标状态。
- 想长期保留多个光标，得配合
Ctrl + U（撤销光标操作）来回滚误删，或用Ctrl + Shift + L先转成稳定选区 - 在折叠代码块里
Alt + Click，光标可能插进折叠区域内部，但展开后位置偏移——因为折叠改变了实际行号映射 - 远程开发（SSH/Dev Container）下，鼠标事件延迟高时，
Alt + Click容易被识别为普通单击，建议改用Ctrl + Alt + ↑/↓替代
真正卡住效率的，往往不是记不住快捷键，而是没意识到 VSCode 的光标和选择模型始终依赖“当前上下文”——文件类型、折叠状态、插件介入、甚至光标初始位置，都在悄悄改写快捷键的实际行为。
