ctrl+shift+l后光标默认在行尾而非行首，需按home或cmd+←跳至行首；缩进不统一时home停在缩进起点，应改用ctrl+home/cmd+home直达绝对行首。
Ctrl+Shift+L 后光标默认在行尾，不是行首
这是最常翻车的点：选中多行 → 按 Ctrl+Shift+L（Windows/Linux）或 Cmd+Shift+L（macOS）→ 所有光标落在换行符前，也就是每行末尾。此时直接输入，字符会加在行尾，而非你想要的行首。
必须立刻按 Home（Windows/Linux）或 Cmd+←（macOS），所有光标才会跳到行首位置。若某行有缩进，Home 默认停在缩进起点，再按一次才能到真正行首；更稳的做法是用 Ctrl+Home（Win）或 Cmd+Home（Mac）直抵绝对行首。
- 别先
Ctrl+A全选再按Home：那只会把光标移到第一行开头，其余行无响应 - 列选择（
Alt+Shift+拖拽）看似直观，但只要缩进不统一（比如混用 Tab 和空格），光标就会错位，加在缩进中间而非行首 - Vintage 模式（Vim 插件）下
Ctrl+Shift+L被重映射，会失效——关掉该模式或手动改快捷键
正则替换加行首字符：^ 不等于 ^.*
^ 在 Sublime 里默认逐行匹配行首位置，前提是右下角 .* 按钮已点亮（启用正则模式）。很多人输完 ^ 就点全部替换，结果没变化——其实是 .* 没开，^ 被当成了普通字符。
真正要“添加”，必须只匹配位置，不破坏原内容。所以查找栏填 ^，替换栏填你要加的字符（如 //）；如果填了 ^. 或 ^.*，整行会被替换掉，只剩前缀。
- 空行也会被
^匹配，加//后变成//，不是 bug，是设计如此 - 混合换行符（
\r\n和\n共存）会导致部分行漏匹配，操作前先Ctrl+Shift+P→ 输入Set Line Endings: Unix统一为 LF - 文件带 BOM 时，
^可能匹配不到首行开头，File → Save with Encoding → UTF-8可解决
行尾加字符：$ 要避开 \n 按钮干扰
行尾操作推荐正则替换，比多光标更稳——因为行长度差异大，Ctrl+L 选行 + Ctrl+Shift+L + End 容易在长文件中漏行或卡顿。
打开 Ctrl+H，勾选 .*，查找填 $，替换填你要加的内容（如 ;）。注意：$ 匹配的是“行尾位置”，不是换行符本身，所以内容会插在换行符前面，不会连成一行。
- 别勾选右下角的
\n（“匹配换行符”）按钮，否则$行为异常，空行可能不生效 - 如果某行结尾有空格或制表符，
$仍插在它们前面；想插在空白之后，得用\s*$查找，替换为;$0（$0表示原匹配内容） - 加双引号不用转义，替换栏直接写
"即可
非空行/跳过注释：正则条件匹配靠先行断言
纯多光标做不到“只给非空行加”或“跳过已有 // 的行”，这时必须上正则。Sublime 用的是 Boost 正则引擎，对 (?=\S)、(?!//) 这类先行断言支持不稳定——有时报错，有时静默失败。
动手前务必拿三行测试：查找 ^(?=\S) 看是否只匹配非空行；查找 ^(?!// )（注意空格）看是否跳过已有注释行。别信文档，以实测为准。
-
^(?=\S)中的\S是“非空白字符”，确保行首不是空格、Tab 或换行 -
^(?!// )的空格不能省，否则//user_id里的//也会被误判 - 大文件（>10k 行）下多光标响应慢半秒，正则替换几乎无感，优先选它
Ctrl+Shift+L + Home，带条件过滤就切正则，别硬套一个方法到底。缩进不齐、编码混乱、Vintage 开着——这些细节一漏，前面步骤全白做。
