Sublime默认快捷键Ctrl+Shift+↑/↓（Win/Linux）或Cmd+Shift+↑/↓（macOS）调用swap_line_up/down命令，实现相邻行内容对调；失效常见于输入法中英文切换、Vintage插件Normal模式拦截及系统级热键冲突。
Sublime 没有真正“两行互换”的原子命令，但 Ctrl+Shift+↑/↓（Windows/Linux）或 Cmd+Shift+↑/↓（macOS）能实现等效效果——它调用的是 swap_line_up 和 swap_line_down，本质是相邻行内容对调，不是剪切粘贴，也不产生空行。
为什么按了没反应？先查这三处静默拦截点
快捷键失效几乎从不因为 Sublime 本身坏了，而是被外部机制吞掉了：
- 输入法处于中文状态（尤其搜狗、微软拼音），
Ctrl+Shift+↑被绑定为中英文切换 —— 切到英文再试 - Vintage 插件开着且在 Normal 模式，
Ctrl+Shift+↑被当 Vim 导航键处理 —— 按i进 Insert 模式再操作，或临时禁用 Vintage 键绑定 - 系统级热键冲突：Windows 上 NVIDIA 控制面板、远程桌面工具；macOS 上 Mission Control 默认占用了
Cmd+↑—— 进系统设置关掉对应快捷键
swap_line_up 和 move_line_up 到底该信谁？
菜单里显示 “Swap Line Up”，但很多人误以为它和 move_line_up 是一回事。其实：
-
swap_line_up：第 4 行和第 5 行内容互换，其他行不动；多行选中时，只作用于选区首行与它上一行的交换 -
move_line_up：把第 5 行整个提到第 4 行上方，原第 4 行变成第 5 行（位移，留空行）；这不是你想要的“对调” - 默认快捷键绑定的是
swap_line_up，不是move_line_up；如果你手动在 Key Bindings 里把它改成move_line_up，反而会导致多行选中行为异常、撤销链断裂
多行选中后怎么避免错位？关键看选区边界
选中多行再按 Ctrl+Shift+↑，不是整体上浮一格，而是整块和「选区起始行的上一行」做交换：
- 选中第 7–9 行按
Ctrl+Shift+↑→ 第 7–9 行和第 6 行互换位置 - 选中第 1–2 行再按
Ctrl+Shift+↑→ 静默失败（已到文件顶部，无上一行可交换） - 想把第 10 行直接塞到第 2 行上方？得连按 8 次，或改用鼠标拖拽行首空白区插入
- 缩进完全保留，哪怕你把一个
if块拖到函数外，它还是顶格缩进 4 空格 —— Sublime 不校验语法层级，也不自动调整
真正容易被忽略的是：Sublime 的行交换完全不感知折叠状态、不检查缩进合法性、不提示语义错误。它只做字符串级别的位置对调，其余责任全在你手上。
