ctrl+g跳转位置准确，光标落在物理行首而非视觉首字符；状态栏ln/col显示即真实位置，软换行或缩进导致的“没到”是视觉误差。

Ctrl+G跳转后光标“没到位置”？先看状态栏再按→

跳转命令本身没问题，但你看到的“不在目标行”往往是软换行或缩进引导线造成的视觉误差。Sublime 的 Ctrl+G（Windows/Linux）或 Cmd+G（macOS）永远落到物理行首，不是你肉眼看到的“第一列可见字符”。

• 状态栏显示 Ln 127, Col 1 就是准确落点，哪怕这行有 4 个空格缩进
• 启用 word_wrap: true 时，长行被折成多行，Ctrl+G 127 仍跳到第 127 行开头——只是你得按 → 键才能从换行断点走到实际内容起始处
• 如果状态栏不显示行号，右键状态栏 → 勾选 Show Line Numbers，否则双击无效
• 大文件跳转慢？不是跳转逻辑卡，而是语法高亮插件（如 BracketHighlighter）在渲染时拖慢；临时切到 Plain text 语法再试

Shift+Ctrl+End选不到文件尾？检查光标起始位置

Shift+Ctrl+End（Win/Linux）或 Shift+Cmd+End（macOS）只选中“从当前光标到文件末尾”，不是“从当前行开头到文件末尾”。光标在哪，起点就在哪。

海豚AI学

一款面向学生学习场景的智能学习产品，为日常学习和知识理解提供AI辅助服务。

下载

• 光标停在某行中间（比如第 89 行第 5 列），选区就从那个字符开始，前面 4 个字符不会被包含
• 光标已在最后一行，Shift+Ctrl+End 只选中从该位置到行尾，不是整行——想选整行，先按 Ctrl+Home 回行首，再按快捷键
• 别用 Ctrl+A 后手动删前面部分：效率低、易漏删、还可能误删注释块
• 选完立刻执行 Ctrl+/ 注释？注意：若选区跨行不完整（比如卡在中间一行的第 3 个字符），只有完整行会被加 //

Ctrl+Shift+L后Home/End失效？←键才是真·行首定位器

Ctrl+Shift+L 把每行末尾变成独立光标，但 Home 在 Sublime 中行为不稳定：有缩进时停在缩进起点，开了 soft wrap 时停在视觉行首，空格结尾时甚至卡在空白里。而 ←（左箭头）永远向左移动一个字符，可控性远高于 Home。

• 标准流程：选中目标行 → Ctrl+Shift+L → 按一次 ← → 所有光标瞬间落到各自行最左非空白字符前（即物理行首）
• 空行也会被赋予光标，输入 // 后变成 //\n；如需跳过，提前用正则 ^\s*$ 过滤
• Vintage 模式下 Ctrl+Shift+L 被重映射为“选中到行尾”，根本不会生成多光标——关掉 Vintage 或改用正则批量处理
• 加行尾内容（如分号）时，End 键常停在末尾空格上，导致输入内容落在空格之后；建议先用 \s*$ 清理行尾空白

列编辑和多光标混用时缩进错位？Alt+拖拽比键盘更稳

用 Ctrl+D 或 Ctrl+Shift+L 配合 Home/End 处理对齐问题，容易因缩进不一致导致光标偏移。真正可靠的列对齐操作，是直接用鼠标+Alt（Win/Linux）或 Option（macOS）拖出矩形选区。

• 按住 Alt 键，从第一行目标列拖到最后一行对应列，松手即得垂直矩形选区，无视缩进、空格、制表符差异
• 键盘方式 Ctrl+Alt+↑/↓（Win/Linux）或 Cmd+Option+↑/↓（macOS）适合小范围纵向扩展，但一旦遇到混合缩进（空格+Tab），光标会错列
• 列编辑后直接输入，内容会严格对齐到所选列位置；而多光标模式下，所有光标都基于各自行的原始位置，无法强制对齐
• 列选区不能跨折叠代码块（如函数体折叠后），此时只能先展开再操作

真正的难点不在记住快捷键组合，而在理解 Sublime 的“物理行”模型——它不按你眼睛看到的排版来算位置，也不替你做智能对齐。所有看似反直觉的行为，比如 Home 不跳到真行首、Shift+Ctrl+End 不从行头开始选，其实都是这个模型的必然结果。接受它，比试图绕过它更省时间。