ctrl+shift+↑/↓（windows/linux）或 cmd+shift+↑/↓（macos）是sublime text中唯一原生、免插件、不走剪贴板的整行移动方式，但实际执行的是move_line_up/down物理位移而非交换，且易被输入法、vintage插件或系统热键静默拦截；需确保英文输入状态、insert模式及关闭冲突系统快捷键，光标须位于未选中文本的任意位置（含缩进空格）才触发，多行移动需用ctrl+l/cmd+l选中，鼠标拖拽须在行号右侧灰白区操作，且该功能仅移动纯文本行，不维护语法结构或缩进。
Ctrl+Shift+↑/↓（Windows/Linux）或 Cmd+Shift+↑/↓（macOS）是唯一原生、免插件、不走剪贴板的整行移动方式——但它不是“交换”，而是物理位移，且极易被静默拦截。
为什么按了没反应？先查这三处硬拦截点
这不是功能失效，是快捷键被系统或插件吞掉：
- 输入法处于中文状态（尤其是搜狗、微软拼音），
Ctrl+Shift+↑被当成中英文切换热键 → 切到英文再试 - Vintage 插件开着且在 Normal 模式，
Ctrl+Shift+↑被当 Vim 导航键忽略 → 临时按i进 Insert 模式验证 - 系统级热键冲突：Windows 上 NVIDIA 控制面板、罗技 G HUB；macOS 上 Mission Control 默认绑定了
Cmd+↑→ 进系统设置关掉「调度中心」或「虚拟桌面」类快捷键
光标在哪才触发移动？Sublime 只认“完整行上下文”
它对“当前行”的判定极严格，不响应片段选中：
- 光标停在任意位置（哪怕只是缩进空格里），未选中任何文本 → 移动该行
- 用
Ctrl+L（Windows/Linux）或Cmd+L（macOS）选中当前行 → 移动该行 - 连按多次
Ctrl+L→ 向下累加选中连续多行，整块移动 - 只选中某一行中间的几个字符 → 不触发，静默失败
- 用
Ctrl+Click添加多个不连续光标 → 各行独立移动，不联动
swap_line_up 和 move_line_up 到底谁在干活？
菜单里显示 “Swap Line Up” 是历史命名误导，实际默认快捷键绑定的是 move_line_up：
-
swap_line_up：第 4 行和第 5 行内容互换，总行数不变，适合快速修正相邻顺序 -
move_line_up：把第 5 行整个提到第 4 行上方，原第 4 行变成第 5 行，产生位移效果 - 如果你在
Key Bindings – User里手动绑了swap_line_up到Ctrl+Shift+↑，多行选中时行为会异常、撤销链断裂
鼠标拖拽整行比快捷键更直观，但触发位置很关键
原生支持，无需插件，天然绕开所有快捷键冲突：
- 把光标移到行号右侧、代码左侧的灰白空白区（不是代码内，也不是行尾空格），鼠标变成小手图标 ✋ 后按住左键拖动
- 拖到目标行上方松手 → 插入到该行之前；拖到下方松手 → 插入到该行之后
- 拖动过程中会出现一条粗横线指示插入位置，支持跨多行精准落点
- 如果光标在代码内部或行尾拖拽，会变成文本选择或复制，不是移动
真正容易被忽略的是：Sublime 的行移动完全不校验语法、缩进层级或折叠状态。它搬的是纯文本行，不是逻辑块。重构时若依赖它自动维持作用域边界或缩进对齐，大概率要手动补救。
