sublime text 中 ctrl+shift+↑（windows/linux）或 cmd+shift+↑（macos）实际执行 move_line_up（上推一行），非真正交换；失效常见于输入法中英文切换、vintage 插件 normal 模式拦截、系统级热键冲突；需整行选中（ctrl+l/cmd+l）才生效，且不校验缩进或折叠逻辑。
Sublime Text 没有真正意义上的“两行交换”原子命令，但用 Ctrl+Shift+↑（Windows/Linux）或 Cmd+Shift+↑（macOS）就能达到等效效果——它不是交换，而是把当前行**上推一格**，视觉上就是和上一行“换了位置”。
为什么按了没反应？先查这三处拦截点
这不是功能失效，是快捷键被静默吞掉了：
- 输入法处于中文状态（尤其搜狗、微软拼音），
Ctrl+Shift+↑常被绑定为中英文切换 —— 切到英文再试 - Vintage 插件开着且在 Normal 模式，
Ctrl+Shift+↑被当 Vim 导航键处理 —— 临时按i进 Insert 模式再操作 - 系统级热键冲突：Windows 上 NVIDIA 控制面板、远程桌面工具；macOS 上 Mission Control 默认占用了
Cmd+↑—— 进系统设置关掉对应快捷键
Ctrl+Shift+↑ 和 swap_line_up 不是一回事
很多人误以为快捷键调用的是 swap_line_up 命令，其实默认绑定的是 move_line_up：
-
move_line_up：把第 5 行提到第 4 行上方，原第 4 行变成第 5 行（位移，留空行） -
swap_line_up：第 4 行和第 5 行内容互换，其他行不动（真交换，不产生空行） - 菜单里显示 “Swap Line Up” 是历史遗留命名误导，实际快捷键干的是位移活
- 如果你手动在 Key Bindings 里绑了
swap_line_up到Ctrl+Shift+↑，反而会导致多行选中时行为异常、撤销链断裂
多行一起动，但必须是“整行选中”
选区类型决定行为，不是“看起来像整行”就生效：
- 光标停在任意位置（哪怕缩进空格里），未选中任何文本 → 触发单行位移
- 按
Ctrl+L（Windows/Linux）或Cmd+L（macOS）→ 精准选中当前整行 - 连续按
Ctrl+L→ 向下累加选中多行，整个块一起移动 - 只选中某行中间几个字符 → 命令静默失败，不报错也不动
- 用鼠标拖选跨行但没包含末尾换行符 → 最后一行可能被截断，反转或移动时丢内容
真正容易被忽略的是：Sublime 的行移动完全不校验语法或缩进层级。把一个 if 块移到函数外，缩进不会自动调整；跨折叠区域移动时，也不会提示“这里不能放”。它只搬行，其余责任在你手上。
