vscode 默认行移动快捷键常被系统、输入法或插件拦截，应改用 ctrl+shift+↑/↓（win/linux）或 cmd+shift+↑/↓（macos）；选中状态决定移动范围，格式化器可能造成缩进错乱。
VSCode 默认用 Alt+↑/Alt+↓（Windows/Linux）或 Option+↑/Option+↓（macOS）移动整行，但这个组合键在多数真实开发环境中极易失效——不是功能坏了，而是被系统、输入法或插件“劫持”了。
为什么 Alt+↑ 按了没反应？常见拦截源就这几个
这不是 VSCode 配置问题，而是快捷键事件根本没传进来：
- Windows 上搜狗、微软拼音等中文输入法默认把
Alt+↑绑定为“中英文切换”，直接吞掉按键事件 - macOS 系统级快捷键（如 Mission Control、调整音量）会抢占
Option+↑/Option+↓，需在「系统设置 → 键盘 → 快捷键」里手动关掉 - 远程桌面（如 Windows Remote Desktop、AnyDesk）默认把
Alt键留在本地，远端 VSCode 完全收不到 - 装了
Vim或VSCodeVim插件后，Alt键常被映射成<c-k></c-k>类操作，优先级高于原生移动行命令
怎么确认和修复绑定？别猜，直接查快捷键面板
按 Ctrl+K Ctrl+S（Windows/Linux）或 Cmd+K Cmd+S（macOS）打开快捷键设置，搜索以下两个命令：
editor.action.moveLinesUpActioneditor.action.moveLinesDownAction
看右侧是否显示 Alt+↑ 或 Alt+↓；如果显示 —、灰色或标红 conflict，说明已被覆盖或禁用。右键对应条目 → “更改键绑定”，推荐改成更稳妥的组合：
-
Ctrl+Shift+↑/Ctrl+Shift+↓（Windows/Linux） -
Cmd+Shift+↑/Cmd+Shift+↓（macOS）
这两个组合在几乎所有环境都稳定，且不会和输入法或系统热键撞车。注意它们的 when 条件里带 !editorReadonly，能避免在只读文件里误触发。
选中多行时行为不一致？关键看“是否完整选中”
VSCode 对“选中状态”的判断很细，直接影响移动范围：
- 未选中文本：光标在哪行，就移动哪一行（整行带换行符）
- 选中跨行部分文本（比如从第 3 行中间拖到第 5 行中间）：
Alt+↑只移动第 3 行，其余不动 - 选中连续完整行（如用
Shift+↓从第 2 行首拉到第 4 行尾）：三行一起移动，相对顺序不变 - 光标分散在多行（如按住
Ctrl点击第1、3、5行）：所有光标所在行同时移动，哪怕不连续
想精准选中整行又不想鼠标拖？把光标放任意位置 → 连按两次 Home（到行首前）→ Shift+End，就能选中本行全部内容含换行符。
移动后缩进错乱？大概率是格式化器在“帮忙”
VSCode 移动行本身不改缩进，但如果你开了 editor.formatOnPaste 或 editor.formatOnSave，移动后可能触发自动重排，导致看起来“移歪了”：
- 临时验证：关掉
editor.formatOnPaste，再试一次移动 - 项目级排查：检查右下角语言模式是否正确识别（如 Python 文件显示为 Plain Text，Prettier 就不会按 Python 规则格式化）
- 缩进突变常见于 Prettier 配置
tabWidth: 2但项目用 4 空格，移动后粘贴触发格式化，就把缩进强行压成 2 格
真正容易被忽略的是：VSCode 的行移动完全不感知语法结构。交换 if 条件行和 body 行，它照做——不会警告你逻辑已断裂。这种“纯文本搬运”特性在快速重构时高效，但也要求你始终对代码结构保持手动校验。
