Sublime默认整行移动是位移而非交换，Ctrl+Shift+↑调用move_line_up命令；若无效需检查输入法、Vintage插件或系统热键冲突；仅完整行选中或光标在行内才触发；swap_line_up才是真交换，误绑会导致逻辑错乱。
Sublime 默认的整行上下移动不是“交换位置”，而是“位移插入”——按 Ctrl+Shift+↑（Windows/Linux）或 Cmd+Shift+↑（macOS）会把当前行（或选区）整体上推一行，原位置空出，其他行自动让位。所谓“交换”是常见误解，真正叫 swap_line_up 的命令行为完全不同，用错会导致逻辑错乱。
Ctrl+Shift+↑ 没反应？先查这三处拦截点
这不是功能坏了，是快捷键被卡住了：
- 输入法处于中文状态（尤其是搜狗、微软拼音），它们常把
Ctrl+Shift+↑绑定为中英文切换 —— 切到英文输入法再试 - Vintage 插件开着且在 Normal 模式，
Ctrl+Shift+↑被当 Vim 导航键吞掉 —— 临时按i进 Insert 模式，或去Preferences → Key Bindings – User禁用对应绑定 - 系统级热键冲突：Windows 上 NVIDIA 控制面板、远程桌面工具，macOS 上 Mission Control 都可能劫持该组合 —— 系统设置里关掉相关快捷键
只选中几个字符，为什么行不移动？
Sublime 的行移动逻辑极严格，只响应“完整行上下文”：
- 光标在行内任意位置、未选中任何文本 → 移动当前行
- 用
Ctrl+L（macOS 是Cmd+L）选中当前行 → 移动该行 - 连按
Ctrl+L多次 → 向下累加选中连续多行，整块移动 - 只选中某一行中间的 3 个字母 → 不触发，静默失败
- 用
Ctrl+Click添加多个不连续光标 → 不触发，各行不联动
swap_line_up 和 move_line_up 到底有什么区别？
这是最容易踩坑的核心点：swap_line_up 是交换，move_line_up 才是位移。但 Sublime 默认快捷键绑定的是后者，而菜单里显示的 “Swap Line Up” 名称极具误导性：
-
swap_line_up：把第 5 行和第 4 行内容互换，不改变其他行顺序 —— 对多行选区只作用于首行，其余不动 -
move_line_up：把第 5 行整个提到第 4 行上方，原第 4 行变成第 5 行 —— 这才是你想要的“移动” - 默认快捷键
Ctrl+Shift+↑实际调用的是move_line_up，不是swap_line_up - 如果你在用户 keymap 里手动绑了
swap_line_up到Ctrl+Shift+↑，就会发现移动后顺序反常、撤销链断裂
移动后缩进错乱、光标跳到行首？这不是 bug
Sublime 不做语法分析，只做纯文本搬运：
- 缩进原样保留：Tab + 2 空格还是 Tab + 2 空格；混用空格和 Tab 的文件移完视觉错位，但这是你源码的问题，不是编辑器问题
- 光标永远停在新位置第一列，不会维持你在第 17 列的原始偏移
- 多行选区移动后，所有光标合并为一个，不保留多光标结构
- 移动到文件首尾时会静默失败（不报错也不提示），得自己留意边界
真正容易被忽略的，是“移动后是否还符合语义”——Sublime 把 return true 拖到 if 前面，它不会拦你，也不会高亮警告。你得自己确认逻辑是否成立。
