Ctrl+Shift+Enter是VSCode原生命令，用于在当前行上方插入新行并保持缩进对齐，光标移至新行末尾；Ctrl+Alt+Enter则在下方插入，光标位置不变，二者稳定可靠、无需配置。
Ctrl+Shift+Enter 和 Ctrl+Alt+Enter 是原生命令，不用配置
VSCode 本身已内置 editor.action.insertLineBefore 和 editor.action.insertLineAfter 两个命令，对应快捷键就是 Ctrl+Shift+Enter（Windows/Linux）或 Cmd+Shift+Enter（macOS）插入上一行，Ctrl+Alt+Enter（Windows/Linux）或 Cmd+Option+Enter（macOS）插入下一行。不需要手动修改 keybindings.json，也不依赖语言模式或扩展。
这两个操作是「插入新行」，不是「光标跳转」：它会在当前行严格上方/下方新增一行，保持缩进对齐，且不触发格式化、不干扰多光标、不激活补全提示。
- 光标必须落在某一行的文本范围内（哪怕只在第一个字符前），不能悬停在行尾换行符外或空白行正中间
- 如果当前行为空，
Ctrl+Shift+Enter仍会插在它上方——不是“移到上一行再回车”，而是无条件插入 -
Ctrl+Alt+Enter插入后光标留在原位置，不自动移动；而Ctrl+Shift+Enter会把光标移到新行末尾
为什么不要用 Shift+Enter 或 Ctrl+Enter 替代
Shift+Enter 在多数语言中被映射为「在当前行下方插入新行并换行」，但它不是原生命令，行为不稳定：
- 会被 Prettier、ESLint 自动修复等扩展拦截或重映射，尤其在保存时触发格式化后可能失效
- 在终端面板里，
Shift+Enter直接执行命令，根本不会插入行 - 某些键盘布局（如部分 Mac 外接键盘）会将
Cmd+Shift+Enter识别为系统级快捷键，但Shift+Enter更容易被输入法劫持
Ctrl+Enter 是另一个常见误选：它实际绑定的是 editor.action.insertLineAfter 的旧别名，但在 VSCode 1.80+ 中已被弃用，部分版本中它和 Ctrl+Alt+Enter 行为不一致，甚至在 Markdown 或 JSON 模式下完全无响应。
快捷键冲突时怎么快速定位和修复
按了没反应？大概率是快捷键被覆盖或劫持，而不是功能坏了。最直接的验证方式是打开命令面板：Ctrl+Shift+P → 输入 Preferences: Open Keyboard Shortcuts → 搜索 insertLineBefore 或 insertLineAfter，看右侧是否显示正确键位。
- 若显示「(unset)」或绑定到其他组合键，说明被自定义规则覆盖了
- 若显示灰色「—」，说明被某个扩展禁用了（常见于 Vim、Emacs 模式扩展）
- Windows 上中文输入法（如搜狗、微软拼音）常劫持
Ctrl+Alt+↑/↓，但Ctrl+Shift+Enter和Ctrl+Alt+Enter被劫持概率低得多
临时绕过方法：右键点击编辑器左侧行号区域 → 选择「Insert Line Before/After」，可确认命令本身是否可用。
想改快捷键？注意别踩这些坑
虽然不推荐改，但如果团队规范或键盘习惯强制需要调整，务必避开以下组合：
- 别用
Ctrl+K开头的组合——它被 VSCode 内置的「命令前缀键」占用，比如Ctrl+K Ctrl+C是注释，Ctrl+K Ctrl+X是剪切行，冲突风险极高 - 避免与 Emmet 冲突：
Ctrl+Shift+Alt+Enter已被 Emmet 占用为「Expand Abbreviation」，即使你没启用 Emmet，某些主题或语法高亮也会间接加载它 - macOS 上慎用
Cmd+Option组合——系统级「截屏」或「Spotlight」可能已注册，需去「系统设置 > 键盘 > 快捷键」逐项排查
真正容易被忽略的是：插入空行这个动作看似简单，但它隐式依赖编辑器焦点状态和当前视图类型。比如在调试控制台、输出面板或设置 UI 中，Ctrl+Shift+Enter 完全无效——这不是 bug，是设计使然。每次失效，先按 Esc 确保退出所有弹出态，再点一下代码区空白处。
