Sublime的Home键默认跳到代码首字符前而非物理行首，按两次可在缩进终点与代码起点间切换；Ctrl+Home/Cmd+Home直达物理行首，设置"move_to_first_character_on_line": false可强制Home始终为行首。
Home 键为什么总跳不到真正行首？
Sublime 的 Home 键默认行为是“跳到第一个非空白字符前”，不是物理行首——这是绝大多数人困惑的根源。它本质上在模拟 IDE 的“语义起始”，而非文本编辑器的“位置起始”。
- 按一次
Home：光标移到缩进后第一个代码字符前（比如跳过 4 个空格，停在def的d前） - 再按一次
Home（已在该行内容起点）：光标会退回到缩进结束位置，也就是“缩进与代码交界处” - 想一步到位到物理行首？用
Ctrl+Home（Windows/Linux）或Cmd+Home（macOS）
这个行为受设置 "move_to_first_character_on_line": false 控制。设为 false 后，Home 就永远等于行首，End 永远等于行尾（含空白）。但注意：它只改 Home/End，不影响 Ctrl+Left 这类词跳转。
如何让光标精准停在缩进层级边界上？
单纯靠 Home 在「行首」「缩进终点」「代码起点」三者间切换效率低，尤其写 Python 或 YAML 时。Sublime 其实有隐式缩进感知，但需要配合操作才能稳定触发。
-
Shift+Tab：把光标左移至当前缩进层级的起始列（对齐到上一级缩进），比反复按Home更可靠 - 确保
"tab_size"和"translate_tabs_to_spaces"设置一致，且"detect_indentation": false——混合空格和 Tab 会导致缩进终点判断漂移 - 装插件
Origami后可用Ctrl+K, Ctrl+H直接跳转到当前缩进块头部，适合快速定位函数体、if 分支等逻辑单元
缩进跳转失效的常见干扰项
即使配置正确，Home 或缩进感知类操作仍可能“失灵”，问题往往不在键位本身，而在上下文环境。
- 插件冲突：某些插件（如
Emacs Pro Essentials）会重绑定Home，检查Preferences → Key Bindings – User中是否含"keys": ["home"]的自定义项 - 语法高亮异常：光标所在位置的 scope 不对（比如本该是
source.python却显示text.plain），用Tools → Developer → Show Scope Name确认 - 文件缩进不统一：已有文件混用 2/4 空格或空格+Tab，
"detect_indentation": true（默认）会锁定错误风格，建议先手动执行View → Indentation → Convert Indentation to Spaces
要不要关掉自动缩进检测？
关掉 "detect_indentation": false 是让缩进行为可预测的最简单方式，尤其当你协作的项目已明确缩进规范（如 PEP 8 要求 4 空格）。
- 开启时：Sublime 会在打开文件时“猜”缩进风格，并覆盖你的
tab_size设置；后续手动缩进也可能被自动“矫正”成倍数（比如你按一次Tab，它却补了 2 个空格） - 关闭后：所有操作严格按用户设置执行，
Ctrl+]加缩进就是加tab_size个空格，Home行为也彻底稳定 - 代价是：需手动统一已有文件缩进，但一次做完即可，比每次调试跳转逻辑更省时间
真正容易被忽略的是：缩进跳转不是纯按键问题，而是缩进格式、语法识别、键绑定三层叠加的结果。调一个参数不如先确认 scope 是否正确、文件是否混缩进、有没有插件偷偷劫持了 Home。
