Ctrl+Shift+L不会跳过空行，只要选区含空行（含换行符\n）就会生成光标，且光标落在行首；需前置清理伪空行（如^\s*$正则替换）或仅选中非空行（^\S.*$）再执行，否则输入会污染空行。
Ctrl+Shift+L 生成光标后，空行也占一个光标位
Sublime 的 Ctrl+Shift+L 不会自动跳过空行——它只认换行符 \n，只要选区里有某行（哪怕全空），就会在该行末尾放一个光标。你看到光标停在空行开头，是因为空行没内容，光标默认落在行首位置，输入时直接写进空行里，比如输 // 就变成 //\n，反而多出带注释的空行。
常见误操作：
- 用鼠标拖选多行，末尾没盖住换行符 → 实际只选中单行 →
Ctrl+Shift+L只出一个光标，根本没触发多行逻辑 - 提前用
Ctrl+A全选再Ctrl+Shift+L→ 所有空行都被赋予光标，且光标落在行首，极易误改 - 空行含不可见字符（如
\u200b或\u00a0）→ 看似空，实则被当作“非空行”，光标落点不可预测
真正跳过空行，得先清理或过滤
Sublime 没有“跳过空行”的快捷键开关，必须靠前置处理把空行从选区里剔除，或者让它们不参与后续编辑。最稳路径是两步走：先识别/删掉伪空行，再对剩余行操作。
推荐做法：
- 先执行正则替换
^\s*$清空所有真·空行和伪空行（含空格、Tab、\r），确保选区干净 - 若不能删空行（比如配置文件要求保留结构），就用正则选中非空行：
^[^\s\r\n].*$，然后Ctrl+Shift+L—— 这样光标只落在非空行末尾 - 粘贴前检查：打开
View → Show White Space，看空行是否显示·或→，确认有没有隐藏字符干扰
加前缀时，Home 键在空行上行为异常
按 Home 想把所有光标拉到行首，但空行上它停在开头，而有内容的行可能停在缩进起点——这不是 bug，是 Home 默认行为：有缩进时第一次按停在缩进边界，第二次才到真正行首。空行没缩进，Home 直接停在开头，结果你输 //，空行就变成 //\n，而非你想要的跳过。
更可控的替代方案：
- 不用
Home，改用←（左箭头）：它始终向左移动一个字符，空行上按一次就到开头，有内容的行按多次可退到最左；配合Ctrl+Shift+L后快速统一到位 - 想加前缀又不想碰空行？列选择更可靠：用
Shift+Alt（Win/Linux）垂直拖选目标行的行首位置，再输入，空行自然被排除在外 - 如果空行集中在中间，手动
Ctrl+Click点击非空行行首加光标，比全选再过滤更快
空行残留导致批量操作失败的真实场景
比如你在 JSON 配置里批量给 key 加引号，用 Ctrl+D 选中所有 key:，结果空行里的空白也被算作匹配项——因为 key: 后面没内容，Ctrl+D 会把光标停在空行开头，一输 " 就污染了结构。
关键细节：
-
Ctrl+D不区分上下文，它只找字面匹配。空行里没有key:，但它会把光标放在空行开头，等你输入，等于“强行插入” - 空行末尾没换行符（EOF 前无
\n）时，Ctrl+Shift+L可能不为其生成光标，造成漏改——这不是一致行为，取决于文件保存状态 - 插件如
TrailingSpaces或EditorConfig可能修改空行判定逻辑，关掉它们再测试，避免干扰
真正容易被忽略的是：空行是否“可见”不等于它是否“存在”。复制粘贴来的文本、Git diff 生成的 patch、甚至某些 LSP 插件输出，都可能带 Unicode 隐形字符。不打开 Show White Space，你永远不知道光标为什么停在奇怪的位置。
