Sublime中Python多行缩进应使用Ctrl+]和Ctrl+[而非Tab键，因Tab默认触发补全而非缩进；需确保选区准确、语法标识正确，并在Python专属设置中显式配置tab_size和translate_tabs_to_spaces。
Sublime 里 Python 多行缩进，别用 Tab 键——它根本不是缩进命令，而是补全触发器，90% 的缩进错乱都源于误按 Tab。
为什么 Tab 和 Shift+Tab 在 Python 文件里基本失效
你选中 5 行按 Tab，结果只动了第 1 行、弹出补全菜单、或干脆没反应——这不是快捷键坏了，是 Sublime 默认把 Tab 绑定给 auto_complete 命令。尤其当光标停在字符串内、函数名后、引号中间或 JSX 标签里，Tab 会优先调用插件（如 Emmet、AutoFileName）补全逻辑，完全绕过缩进。
- 右下角显示
Plain Text时，Tab只插入原始\t，不识别冒号、括号等 Python 语法结构 -
detect_indentation开启状态下，Sublime 会扫描文件开头几行，悄悄把你的Tab行为重定向为 2 空格或 Tab 字符，和你设的tab_size冲突 - 未选中任何内容时，
Tab只影响当前行首；若光标在行中，可能只插入字符，不改变缩进层级
Ctrl+] 和 Ctrl+[ 是唯一可靠的多行缩进入口
这两个命令专为块级缩进设计：不分析语法、不触发补全、不矫正空格数，只机械增减行首空白。对 Python 来说，它严格保持相对层级——选中 if 块里的 print 和 return，按一次 Ctrl+]，两者统一右移一档，不会把 return 拉到和 if 同列。
- 未选中时，只作用于当前行首（适合微调单行，比如补一个
else的缩进） - 选中多行时，对每行统一加/减一档缩进（由当前文件的
tab_size和translate_tabs_to_spaces决定） - 折叠区域（
Ctrl+Shift+[折起来的代码）不参与缩进计算，缩进前务必先展开 - 对
.json、.md、.txt等无语法约束的文件同样生效
选区不准，缩进就一定错
缩进漏行、缩错层级、甚至方向反了，90% 是因为选区没对准逻辑结构。比如光标停在 if 行但只选了半行，Ctrl+] 就只缩进那半行；又或者 def func(): 后面的整个函数体没被完整选中，缩进后直接破坏 Python 的嵌套关系。
立即学习“Python免费学习笔记（深入）”；
-
Ctrl+Shift+M：把光标放在任意括号（{}、[]、()）内，一键选中配对范围内的全部内容 -
Ctrl+Shift+J：光标停在某行，选中所有同缩进层级的连续行（适合缩进整个if块或for循环体） -
Ctrl+Shift+P→ 输入Selection: Expand Selection to Brackets：HTML 标签、JSON 对象、Vue 单文件组件的<script>块都靠它包裹准确
混用空格和 Tab？先归一化再操作
你按 Ctrl+]，结果插入的是一个 \t 字符（宽度由 tab_width 决定），而团队规范要求 4 个空格——这种不一致会在 Git diff 里爆炸式体现，也会让 ESLint 或 Prettier 报错。
- 确认右下角语法标识准确（如 Vue 文件中的
<script>块常被误判为 HTML，需点开手动切到 JavaScript） -
Ctrl+Shift+P→ 输入Indentation: Convert Indentation to Spaces，把已有Tab全转为空格 - 检查用户设置中是否含
"detect_indentation": false，否则打开旧文件时 Sublime 会悄悄覆盖你的tab_size和translate_tabs_to_spaces
真正容易被忽略的，是 Python.sublime-settings 文件里那两行硬编码配置——全局设置里的 "tab_size": 4 对 .py 文件基本无效，必须单独打开语法专属设置并显式写入 "tab_size": 4 和 "translate_tabs_to_spaces": true，否则 Ctrl+] 永远按你“以为”的方式工作，而不是你“需要”的方式。
