Ctrl+Shift+L 的光标默认落在每行换行符前（视觉行尾），非“添加”而是基于选区自动定位；需先选中多行再触发，否则无效。
Ctrl+Shift+L 后光标默认在行尾，不是“加”而是“落点已定”
Sublime 的 Ctrl+Shift+L（Windows/Linux）或 Cmd+Shift+L（macOS）不会“把光标加到行尾”，它会把当前选中区域按换行符切开，**每个光标自动落在对应行的换行符前**——也就是视觉上每行最右、换行前的位置。这个行为是确定的，不依赖设置，也不需要额外插件。
常见误解是以为要先“定位到行尾”再触发，其实顺序反了：必须先有选区（哪怕只选中每行开头一个空格），再按 Ctrl+Shift+L，光标就自然落到行尾。如果没反应，大概率是没形成有效选区——纯空行默认被忽略，全选后未触发行级拆分也会失败。
- ✅ 正确操作：鼠标拖选多行 → 按
Ctrl+Shift+L→ 所有光标已在行尾 - ❌ 错误操作：光标在行间跳动但无选中 → 按
Ctrl+Shift+L无响应 - ⚠️ 插件干扰：Emmet 或 Vintage 模式可能劫持该快捷键；可在
Preferences > Key Bindings中搜索split_selection_into_lines确认绑定
行尾有空格或 Tab 时，→ 和 End 行为不一致
按 →（右方向键）或 End 后光标位置不同：前者逐字符右移，后者直接跳到“逻辑行尾”（即最后一个非空白字符后）。若某行末尾是 ;（4个空格+分号），End 停在分号后，→ 则可能停在空格中间。
想确保光标落在真正换行符前（即“物理行尾”），推荐统一用 End（Win/Linux）或 Cmd+→（macOS）。但注意：某些远程桌面或键盘布局下 End 失效，此时可改用 Ctrl+→（跳到单词尾）或安装 Hard End of Line 插件启用 Move to Hard EOL 命令。
- 有缩进/空格混用时，
End更稳；纯空行上End仍能定位到行尾位置 - 若需紧贴非空白内容插入（如让
;紧挨return x而非空格后），先执行Ctrl+Shift+P→ 输入Trim Trailing White Space清理尾部空白 - 状态栏显示 “× lines selected” 是正常提示，不是错误
正则替换用 $ 时，\n 按钮和空格处理是两大坑
在 Ctrl+H 替换面板中，$ 是行尾锚点，但它匹配的是“换行符之前的位置”。一旦勾选了左下角的 \n（Match newline）按钮，$ 就失效——它会转而匹配实际换行符本身，导致替换内容插入到下一行开头，破坏结构。
另一个问题是尾部空白：$ 不关心空格或 Tab，它就停在换行符前，所以 Replace With: ; 会在空格后面加 ;，变成 ;。这不是 bug，是设计如此。
- ✅ 安全写法：关闭
\n按钮；查找填\s*$（匹配行尾所有空白），替换填;${0}（${0}表示原匹配的空白，保证分号紧贴内容后） - ⚠️ 文件末尾无换行符时，
$仍能匹配最后一行结尾，但若最后一行后有多余\n，可能造成视觉错位；建议开启View → Draw White Space查看真实空白分布 - 空行也会被
$匹配，这是预期行为；若不想处理空行，查找改用[^\r\n]*[^\r\n\s]$（需启用正则）
列选择（Alt+拖拽）根本不适合行尾操作
列选择本质是矩形框选，它按屏幕列数定位，而非按逻辑行。想在每行末尾加字符，你得把鼠标拖到每行最右像素点——但不同行长、字体宽度、缩进方式都会导致列偏移。哪怕所有行都以 ; 结尾，列选也极可能漏掉几行或插错位置。
它唯一适用的场景是：固定宽度字段（如 CSV 第 3 列）、严格对齐的日志时间戳、或已用 Indentation: Convert to Spaces 统一缩进的配置块。对“行尾”这种动态位置，列选是伪解法，容易出错且不可复现。
- 别为了省一次
End去冒险列选；多光标 +End响应更快、容错更高 - 大文件（>5k 行）下
Ctrl+Shift+L有约 300ms 延迟，等所有光标点稳定后再按End，否则部分光标会失焦 - 如果某行意外没被覆盖（比如含 BOM 或混合换行符 \r\n/\n），优先检查编码和行尾格式，而不是重试列选
Ctrl+Shift+L 后那一秒——光标落点是否真的在你认为的“行尾”。空格、缩进、BOM、换行符类型，任何一个变量都会让“看起来一样”的行产生不同的光标行为。看清它，比记住组合键重要得多。 
