sublime text 原生支持 ctrl+shift+↑/↓（win/linux）或 cmd+shift+↑/↓（macos）整行移动，需按住 shift；选中多行可整体平移；代码块移动需插件（如 codeblockmover）或折叠功能配合；缩进块移动需安装 movelines 插件并自定义快捷键。
Sublime Text 里怎么上下移动整行代码
直接用 Ctrl+Shift+↑ 或 Ctrl+Shift+↓（Windows/Linux），macOS 是 Cmd+Shift+↑ / Cmd+Shift+↓。这不是插件功能，是 Sublime 原生支持的「行移动」操作，无需额外配置。
常见错误是误按成 Ctrl+↑（滚动视图）或 Alt+↑（光标多选），结果没动代码，只改了光标位置。确认快捷键时注意 Shift 键必须按下。
- 选中多行后使用，整个选区会一起上下平移
- 光标在行内任意位置（不一定要在行首）都能触发整行移动
- 移动后光标默认落在目标行的原列位置；如果目标行更短，光标会自动贴到行尾
移动代码块（非整行）时为什么没反应
Sublime 的原生移动只认「行」，不识别缩进块、函数体或花括号包裹的逻辑块。move_line_up 和 move_line_down 这两个命令底层只操作 line 单位，遇到部分选中或跨行选区，它要么不动，要么只移动被选中的那几行——不是你想要的“把 if 块整体拖下去”。
真正想移动代码块，得靠插件，比如 CodeBlockMover 或手动配合折叠功能：
- 先用
Ctrl+Shift+[折叠当前代码块（如函数、if 分支） - 再用
Ctrl+Shift+↓移动折叠后的那一行（即折叠标题行） - 最后用
Ctrl+Shift+]展开，整块就到位了 - 注意：折叠依赖语法高亮和
.sublime-syntax文件里的 fold_rules，Python/JS 支持好，某些自定义语言可能不识别
快捷键冲突或失效的几个典型原因
最常踩的坑是系统级或输入法劫持了 Ctrl+Shift+↑/↓。Windows 上某些显卡控制面板（如 NVIDIA 控制面板）、Mac 上的 Spotlight 或输入法切换（比如 macOS 默认的 Cmd+Space 切换输入源，但有些输入法会连带吃掉 Shift 组合键）都会干扰。
验证是否被拦截：打开 Sublime → Preferences → Key Bindings，搜索 move_line，确认默认绑定存在且未被覆盖。如果看到类似这样的自定义绑定：
[{"keys": ["ctrl+shift+up"], "command": "noop"}]
说明它被故意禁用了。删掉这行即可恢复。
- 某些主题或 UI 插件会重映射快捷键，检查
Preferences → Package Settings下有没有相关插件的 keymap 文件 - 远程桌面（如 Windows RDP）有时会吞掉带 Shift 的组合键，本地测试正常但远程不行，换用
Ctrl+K, Ctrl+U（上移）和Ctrl+K, Ctrl+D（下移）这类替代方案更稳
想实现“按缩进层级移动代码块”该怎么做
Sublime 没有内置这个能力，但可以通过正则 + 命令组合模拟。核心思路是：先用 Ctrl+Shift+P 调出命令面板，运行 Indentation: Reindent Lines 确保缩进干净，再用正则选中同级块（比如匹配以相同空格开头、后接非空字符的连续行），最后剪切粘贴——但这手动成本高，不适合高频操作。
更实用的做法是装一个轻量插件：MoveLines（注意不是同名旧版）。它提供 move_lines_up_by_indent 命令，能识别当前行缩进量，向上/向下找到第一个同缩进或更浅缩进的行，把中间所有行当“块”移动。
- 安装后绑定自定义快捷键，例如在用户 keymap 里加：
{"keys": ["alt+up"], "command": "move_lines_up_by_indent"} - 它对 Python 缩进敏感，但对 Tab/Space 混用不友好；建议项目统一用空格缩进
- 如果块里含注释行（# 开头）或空行，它默认跳过，不会破坏结构
真正难的不是怎么动，而是动完之后的缩进对齐和括号匹配——尤其是从 if 块里拖出一行到外面时，很容易漏掉缩进或搞错作用域。动手前最好先保存，或者开个临时窗口试拖。
