ctrl+shift+l后光标默认在行尾，需按home跳至行首；^匹配行首需点亮.*按钮；缩进不统一时应先转空格再操作。
Ctrl+Shift+L 后光标不在行首？按 Home 才算真正到位
Sublime 的 Ctrl+Shift+L（Windows/Linux）或 Cmd+Shift+L（macOS）会把选中多行的每行末尾变成一个光标，不是行首。这是设计行为，不是 bug。直接输字符会加在行尾，而不是你想要的行首。
必须立刻按 Home（Win/Linux）或 Cmd+←（macOS）让所有光标跳到各行开头。有缩进时，第一次 Home 停在缩进起点；若要越过缩进到真正行首（比如 UTF-8-BOM 后或空格前），得再按一次 Home 或改用 Ctrl+Home/Cmd+Home。
- 选区必须包含换行符，否则
Ctrl+Shift+L静默失败（状态栏无提示） - 某行开头是 BOM 时，
Home会卡在 BOM 字节后，建议先执行File → Save with Encoding → UTF-8清除 BOM - 操作中途按了方向键、
Esc或Ctrl+Z，部分光标会消失——每次输入前看一眼状态栏右下角是否还显示 “x cursors”
正则替换加行首内容，.^ 必须点亮 .* 按钮
用 Ctrl+H 打开替换面板，^ 确实能匹配每行开头，但前提是右下角的 .* 按钮必须被点亮。没点它，^ 就是字面量，替换结果是每行开头多出一个 ^ 字符，而不是加前缀。
^ 在 Sublime 中默认逐行生效，不用手动开 m（multiline）标志；但如果你误点了左下角 Alt+M，反而可能干扰逻辑。
- 混合换行符（
\r\n和\n共存）会导致部分行漏匹配，操作前先运行Ctrl+Shift+P → Set Line Endings: Unix统一为 LF - 空行也会被
^匹配，加//后变成//，这是预期行为，不是错误 - 想只给非空行加？搜
^(?=\S)；想跳过已有//的行？搜^(?!// )
缩进不一致时，硬按 Home 会让前缀歪斜
如果目标行缩进混用 Tab 和空格，Home 在不同行停靠位置不同，强行输入只会放大错位。别靠反复调光标对齐，先统一结构。
推荐预处理：选中目标行 → Ctrl+Shift+P → 输入 Indentation: Convert to Spaces，把 Tab 全转为空格；或者用正则一步到位：
查找：^(\s*)(.+)$ 替换：$1#
这样 # 会紧贴原有缩进后内容，不破坏层级。
- 列选择（
Alt+Shift+拖拽）看着直观，但 Tab 宽度不一致时极易错位；开启View → Draw White Space显式查看空白符后再拖更稳 - 加
#、//、-这类符号不影响语法高亮，但可能干扰视觉判断，尤其深色主题下
Vintage 模式下 Ctrl+Shift+L 失效？关掉或换路径
如果启用了 Vintage（Vim）模式，Ctrl+Shift+L 默认被重映射为「从光标到行尾选中」，此时按了也没反应。这不是快捷键冲突，是模式覆盖。
两个选择：关掉 Vintage（Preferences → Package Control → Disable Package → Vintage），或改用正则路径——它不受编辑模式影响，稳定可靠。
- 用正则加行首时，
$匹配行尾，但默认停在换行符前；若某行末尾有空格或 Tab，$会停在它们前面，导致后缀加在空格后。解决方法是把查找内容改成\s*$ - 状态栏显示 “替换 0 处”？检查是否误勾了 “在所选内容中”，而你根本没选任何文本
- 批量删行首字符（如删掉所有
//）：查找^//，替换留空；删行首空白：查找^[ \t]+
实际批量加行首内容，最常翻车的不是不会操作，而是没意识到 Ctrl+Shift+L 后光标默认在行尾、^ 不点亮 .* 就无效、以及缩进不统一直接按 Home 只会让结果更乱。这三个点，漏一个，整批修改就得重来。
