Ctrl+Shift+L后光标默认在行尾，需按Home键移至行首；列选择仅适用于视觉对齐的文本；正则替换启用^前须点亮.*按钮；Ctrl+A无法批量编辑，必须用Ctrl+Shift+L生成多光标。
Ctrl+Shift+L 之后光标不在行首？必须手动按 Home
Sublime 的 Ctrl+Shift+L（Windows/Linux）或 Cmd+Shift+L（macOS）确实能把选中多行转成多个光标，但光标默认落在换行符前——也就是**每行末尾**，不是行首。这是最常被忽略的细节，直接输入会把字符加在行尾。
正确做法是：
- 先用鼠标拖选或多行连续选（
Ctrl+Shift+↑/↓）确定目标范围 - 按
Ctrl+Shift+L，看到每行出现独立光标点 - 立刻按
Home（Windows/Linux）或Cmd+←（macOS）——所有光标会跳到该行文本起始位置 - 若某行有缩进，
Home默认停在缩进开头；要到绝对行首，需再按一次Home或用Ctrl+Home/Cmd+Home
列选择（Alt+Shift+拖拽）适合什么场景？别乱用
列选择本质是矩形框选，它不认“行首”，只认屏幕坐标。所以它稳定的前提是：所有目标行的开头在视觉上严格对齐。
适用情况：
- 处理已统一缩进的代码块（如一组
console.log()调用） - CSV 表头或固定列宽的纯文本数据
- 补全 Markdown 列表符号（
-），前提是每行都从同一列开始
风险点：
- 混用 Tab 和空格时，Tab 宽度不一致会导致列选错位——打开
View → Draw White Space可视化空白符后再拖更准 - 开启软换行（
soft_wrap）时，列选无法跨软换行，操作前建议临时关闭 - 缩进不齐的代码块里强行列选，可能把字符插进缩进中间，而非真正行首
正则替换加 ^ 为什么有时没反应？检查这三点
^ 在 Sublime 中默认逐行匹配，但前提是正则模式必须启用。很多人输完 ^ 就点全部替换，结果没变化，其实是 .* 按钮没点亮。
关键检查项：
- 确认右下角
.*按钮已高亮（即正则模式开启），否则^当普通字符处理 - 避免填
^.或^.*——这会匹配并替换整行内容，只留下你写的前缀 - 混合换行符（
\r\n和\n）可能导致部分行漏匹配，建议先执行Ctrl+Shift+P → Set Line Endings: Unix统一为 LF
补充：空行也会被 ^ 匹配，加 // 后变成 //，这是预期行为，不是 bug。
为什么不能 Ctrl+A 后直接输？光标状态根本不对
Ctrl+A 全选后，看起来是整块高亮，但 Sublime 内部只有一个光标在第一行开头，其余只是选中区域——不是独立光标点。此时按 Home 只会让第一个光标跳到行首，其他位置仍无响应。
后果很直接：
- 输入字符，只在第一行开头生效，其余行完全没变化
- 按
Delete或Backspace，只会删第一行开头，其余行不动 - 哪怕你看到“整片蓝底”，也不代表能批量编辑——必须靠
Ctrl+Shift+L显式生成多个光标
真正触发批量输入的唯一标志，是肉眼可见每行开头都有一个独立闪烁的小竖线（光标点），而不是一块连续高亮。
