Ctrl+Shift+L后光标默认在行尾，需按Home/Cmd+←跳至行首才能批量加前缀；若存在缩进或BOM，需二次定位或统一编码格式。
Ctrl+Shift+L 后光标默认在行尾，不是行首
直接选中多行按 Ctrl+Shift+L（Windows/Linux）或 Cmd+Shift+L（macOS），光标会落在每行换行符前——也就是**行尾位置**，不是行首。此时输入字符，会加在每行末尾，而非开头。
必须立刻补一步：Home（Win/Linux）或 Cmd+←（macOS），所有光标才会同步跳到行首。若某行有缩进，Home 默认停在缩进起点；要到绝对行首，得按两次 Home 或用 Ctrl+Home/Cmd+Home。
- 别先
Ctrl+A全选再按Ctrl+Shift+L：全选后Ctrl+Shift+L仍把光标放在每行末尾，且无法靠一次Home统一跳转 - 缩进不一致时（如混用 Tab 和空格），
Home行为可能不统一；建议先执行Ctrl+Shift+P→ 输入Align Indent或Indentation: Convert to Spaces统一格式 - UTF-8-BOM 编码下，
Home可能被 BOM 干扰，跳不到真正行首；可改用File → Save with Encoding → UTF-8去除 BOM
正则替换加行首字符，^ 不等于 ^.*
打开 Ctrl+H 替换面板，勾选右下角 .*（启用正则），查找栏填 ^，替换栏填你要加的字符（如 //），点“全部替换”——这才是安全加前缀的方式。
^ 匹配的是“行首位置”，不消耗任何字符，所以不会删内容；但很多人误填 ^. 或 ^.*，结果整行被替换成前缀，原内容全丢。
- 空行也会被
^匹配，加//后变成//，这是预期行为，不是 bug - 混合换行符（
\r\n和\n共存）会导致部分行漏匹配；操作前先Ctrl+Shift+P→Set Line Endings: Unix统一为 LF - Sublime 的
^默认就是逐行生效，无需手动开m（multiline）标志；但如果你点了左下角Alt+M开了它，反而可能干扰已有逻辑
加行尾字符，$ 要避开 \n 按钮和尾部空白
同样在替换面板中，正则模式下查找 $，替换为你要加的内容（如 ;），即可批量加在每行末尾。注意：$ 匹配的是“行尾位置”，在换行符之前，所以不会破坏换行结构。
但两个设置容易导致失败：Match newline (\n)（那个 \n 按钮）如果被勾选，$ 就不再匹配常规行尾；另外，若某行末尾有空格或制表符，$ 仍会插在它们前面，而不是“可见内容之后”。
- 想让后缀紧贴非空白内容？查找
\s*$，替换为你的后缀$0（$0表示原匹配的空白） - 最后一行没换行符时，
$依然能匹配其结尾；但若文件末尾有多余\n，可能造成视觉错觉，建议开启View → Draw White Space看清空白分布 - 避免用
\n当替换内容——比如填;\n，会把所有行连成一行；$已隐含位置语义，不需要显式写换行
列选择适合对齐文本，但不适合逻辑行首
按住 Alt+Shift（Win/Linux）或 Cmd+Shift（macOS）垂直拖拽鼠标，能构造竖向矩形选区，松手后输入即同步生效。这招快、直观，但只适用于**缩进严格对齐**的文本块。
一旦某行缩进用 Tab、另一行用 4 个空格，且 Tab 宽度设为 4，视觉上对齐，实际字符位置偏移，列选就会错位——有的加在缩进内，有的加在真·行首。
- Markdown 列表、CSV 字段名、固定宽度日志等对齐结构，列选最稳
- 代码块里嵌套层级不同（如 if 里套 for），缩进天然不齐，此时列选极易出错，应退回
Ctrl+Shift+L+Home路径 - 列选无法跨软换行（
soft_wrap开启时），操作前建议关掉该选项，否则拖拽会断在折行处
Ctrl+Shift+L + Home 是最可控的手动方式；但上千行、需条件过滤（比如“只给非空行加”），就必须用正则，且得亲手验证 ^(?=\S) 在你当前 Sublime 版本里是否真能跑通——Boost 正则引擎对负向先行断言的支持并不稳定。 
