sublime中批量加行首字符的唯一可靠原生路径是ctrl+shift+l拆多光标后按home（win/linux）或cmd+←（macos）跳至行首输入；光标默认在行尾因设计逻辑为落于选区末尾（换行符前），非bug。
直接用 Ctrl+Shift+L 拆出多光标，再按 Home（Windows/Linux）或 Cmd+←（macOS）跳到行首输入——这是唯一可靠、不依赖插件的原生路径。
为什么 Ctrl+Shift+L 后光标默认在行尾？
Sublime 的设计逻辑是：光标总落在选中区域的“末尾位置”，也就是换行符前。这不是 bug，是行为一致性的体现。你没看到光标跳到行首，是因为它根本没被设计成那样。
- 按
Ctrl+Shift+L前必须已选中含换行符的多行文本，否则静默失败（状态栏无提示） - 选区若包含空格或制表符，光标会停在它们后面，导致输入时前缀被“挤”到缩进之后
- 如果某行开头是 BOM（UTF-8-BOM），
Home会卡在 BOM 字节后，而非真正行首；建议先执行File → Save with Encoding → UTF-8
^ 正则替换加前缀，哪些设置不能漏？
正则快，但错一个开关就白忙活：^ 默认逐行生效，但前提是正则模式必须启用，且不能误开 \n 匹配选项。
- 打开
Ctrl+H，务必点击右下角.*按钮启用正则模式；否则^当作字面量，啥也不匹配 -
^本身不需要手动开m（multiline）标志——Sublime 默认就是逐行锚定；但如果你不小心点了左下角Alt+M，反而可能干扰已有逻辑 - 混合换行符（
\r\n和\n共存）会导致部分行漏匹配；操作前先运行Ctrl+Shift+P → Set Line Endings: Unix统一为 LF - 空行也会被
^匹配，加//后变成//，这是预期行为，不是错误
缩进不一致时，前缀歪斜怎么办？
Home 键在不同缩进下停靠位置不同，强行输入只会放大对齐问题。别硬调光标，先统一结构。
- 选中目标行 →
Ctrl+Shift+P→ 输入Indentation: Convert to Spaces，把 Tab 全转为空格 - 或用正则预处理：查找
^(\s*)(.+)$，替换为$1prefix_$2，这样前缀会紧贴缩进后内容，不破坏原有缩进层级 - 列选择（
Alt+Shift+拖拽）看起来直观，但 Tab 宽度不一致时极易错位；开启View → Draw White Space显式查看空白符后再拖更稳
最易被忽略的是：操作中途按了方向键、Ctrl+Z 或误触 Esc，都会让部分光标消失。每次输完前，看一眼状态栏右下角是否还显示 “x cursors”——没这个提示，就说明同步已断。
