Alt+↑/↓（Windows/Linux）或Option+↑/↓（macOS）可直接物理移动整行，但80%“没反应”是因输入法、系统快捷键、Vim插件、终端焦点等提前截获按键；需切英文输入法、查快捷键面板确认editor.action.moveLinesUpAction绑定，并注意选中必须为连续整行且非折叠区域。
Alt+↑/↓（Windows/Linux）或 Option+↑/↓（macOS）能直接物理移动整行，但 80% 的“没反应”不是功能失效，而是按键事件根本没传进 VSCode。
为什么 Alt+↑ 按了没反应
这不是快捷键没开，是系统或插件提前截获了按键：
- 中文输入法（如搜狗、微软拼音）默认用
Alt+↑切换中英文，直接吞掉事件 - macOS 系统级快捷键（Mission Control、显示桌面）占用了
Option+↑，需在「系统设置 → 键盘 → 快捷键」里关掉 - 远程桌面（AnyDesk / RDP）常把
Alt留在本地，远端 VSCode 收不到 - Vim 插件（如
vscodevim）在 Normal 模式下把Alt映射为<c-k>类操作，优先级更高 - 焦点在集成终端（
Ctrl+`打开的那个黑框）里，快捷键只对终端生效
最省事的验证方式：按 Esc 清除选中 → 切出中文输入法 → 确保光标在代码编辑区 → 再试一次。
如何确认和修改 editor.action.moveLinesUpAction 绑定
别猜，直接查内置快捷键面板：
- 按
Ctrl+K Ctrl+S（Windows/Linux）或Cmd+K Cmd+S（macOS）打开快捷键设置 - 搜索
editor.action.moveLinesUpAction和editor.action.moveLinesDownAction - 看右侧是否显示
alt+up；如果显示—、灰色或标红conflict，说明已被覆盖或禁用 - 右键对应条目 → “更改键绑定”，推荐设成：
Ctrl+Shift+↑/Ctrl+Shift+↓（Win/Linux）或Cmd+Shift+↑/Cmd+Shift+↓（macOS）
这两个组合在几乎所有环境都稳定，且 when 条件里自带 !editorReadonly，能避免在只读文件里误触发。
选中多行时 VSCode 怎么判断“动哪几行”
VSCode 对“选中”的理解很细，直接影响移动范围：
- 未选中文本：光标在哪行，就移动哪一行（含换行符），原位置留空行
- 用
Shift+↓从第 2 行首拉到第 4 行尾：三行一起移动，相对顺序和缩进全保留 - 只选中某行中间几个字符：快捷键退化为普通文本块移动，不再按“整行”处理
- 跨折叠区域选中（比如折叠函数里选两行）：VSCode 会临时展开、完整移动、再恢复折叠
注意：跳着选（如 Ctrl+单击）不生效，必须是连续选中的行。
移动后缩进错乱，其实是格式化插件在后台改的
这不是移动功能的问题，而是 editor.formatOnPaste 或 editor.formatOnSave 在你松手瞬间触发了重排。尤其 Prettier 默认 tabWidth: 2，而项目用 4 空格时，一眼就看出“移歪了”：
- 临时验证：设置里搜
format on paste，关闭editor.formatOnPaste - 更稳妥做法：移动前确认右下角语言模式正确（如显示
JavaScript而非Plain Text） - 如果用 Prettier，检查项目根目录
.prettierrc中的tabWidth是否与编辑器设置一致
真正容易被忽略的是：这个操作不可跨文件生效，也不能在折叠区域内部单独交换某一行——折叠状态下，它只作用于可见行，隐藏行会被连带拖动。如果代码结构复杂，先展开再操作更稳妥。
