Ctrl+Alt+↑/↓是唯一真正按列坐标导航的快捷键，严格依据字符索引定位光标，不依赖内容、选区或空格数，但受缩进混用、非等宽字体等因素影响导致视觉偏移。
Ctrl+Alt+↑/↓ 是唯一真正按列坐标导航的快捷键
它不看内容、不依赖选区、也不数空格，只认当前光标在该行的字符索引位置。光标在第 7 列（即第 7 个字符），按下 Ctrl+Alt+↓ 就会在下一行第 7 列插入新光标——哪怕那行只有 5 个字符，光标也会硬插在行尾；哪怕那行是空行，光标就落在行首。
常见失效场景：
- 光标卡在缩进里（比如 Tab 或 4 个空格），新光标也跟着卡在缩进位置；想避开，先按
Home把所有光标拉到行首，再触发Ctrl+Alt+↓ - 某行该列是 Tab，而其他行是空格 → 字符索引一致但视觉错位；用
Ctrl+Shift+P→Convert Indent to Spaces统一后更稳 - 字体不是等宽（如 Segoe UI）→ 中文/英文/符号宽度不一，列坐标和视觉严重脱节；必须换为
Fira Code或Consolas
Alt+鼠标拖拽列选择 ≠ 列导航，而是生成矩形选区
很多人误以为拖完就能直接输入，其实它只是创建了一个“竖向块选区”，Sublime 默认只对第一个光标位置执行输入操作。必须补按 Ctrl+Shift+L 才能把这个矩形区域转为多光标阵列。
关键细节：
- 拖拽起始点决定列基准：从第 12 列开始拖，松手时覆盖了 3 行，就生成一个 3×N 的矩形；但若第 3 行只有 10 个字符，选区会在第 10 列截断，且无任何提示
- 开启
"draw_white_space": "all"可让 Tab 和空格显形，避免因不可见字符导致列偏移 - 列选状态下方向键、
Ctrl+D、Ctrl+U全部失效；必须先按Esc退出列模式才能继续操作
为什么光标看起来对齐，一输内容就偏？
这不是界面 bug，而是 Sublime 的光标定位严格基于字符索引，而非渲染像素。Tab 在文件中是 1 个字符，但可能被渲染为 4 或 8 个空格宽；全角中文占 2 字符宽度，但显示只占 1 个汉字位置。不同行的缩进混用 Tab 和空格时，Ctrl+Alt+↓ 仍按字符数跳，视觉必然漂移。
可验证方式：
- 打开
View → Word Wrap设为false，排除软换行干扰 - 临时启用
"font_face": "Fira Code"，观察竖线光标是否稳定垂直 - 运行
Ctrl+Shift+P→Trim Trailing White Space，清除末尾空格对列计算的干扰
别把 Alignment 插件当光标导航工具
Ctrl+Alt+A 是格式化命令，不是光标定位命令。它不会移动你当前的光标，只扫描已存在的多光标区域，在等号、冒号等符号两侧插入空格实现视觉对齐。
前提条件非常具体：
- 必须已有至少两个光标，且都落在待对齐符号左侧（比如
name = value中的=左边） - 某行缺失该符号（如
age: 25里没有=），该行会被跳过 - 行尾有注释或空格会干扰对齐逻辑；建议批量操作前统一清理缩进和尾部空白
Ctrl+Alt+↓ 都像在赌运气。 
