Sublime多行游标是高效编辑核心能力，非炫技功能：Ctrl+D精准选词需光标在词内、避引号/括号干扰，Escape中断叠加，Ctrl+K跳过误选项；Alt+F3全量匹配受视口和大小写限制；Ctrl+Shift+L拆行前宜先Ctrl+L对齐行首；鼠标拖拽受限于模式与方向，Ctrl+Click更可靠。
Sublime 的多行游标不是“炫技功能”，而是真正在改配置、修 JSON、批量重命名变量、补全 props 或 state 时省掉 80% 重复劳动的核心能力。它不依赖插件，开箱即用，但默认行为和组合键容易误操作——比如按 Ctrl+D 停不下来，或 Alt+F3 选中了不该选的缩写词。
怎么用 Ctrl+D 精准选中目标词，而不是越选越多？
Ctrl+D 的本质是“增量词匹配选择”，它只认当前光标所在位置的完整单词（由单词边界决定），不是模糊字符串匹配。这意味着：
- 光标必须落在目标词内部（不能在词尾空格后），否则会选中空格或换行符
- 如果词被引号/括号包裹（如
"mode"或mode:），默认只选中mode，但若光标在引号内，Ctrl+D会把引号一起带上——这常导致替换后引号错乱 - 连续按
Ctrl+D时，每一下都新增一个匹配项；想中断叠加，直接按Escape退出多游标状态即可 - 遇到不想选的中间项，先按
Ctrl+K，再按Ctrl+D——这个组合跳过当前高亮项，继续找下一个
Alt+F3 为什么有时选得太多，有时又漏掉？
Alt+F3 是全文本范围的“全量词匹配”，但它受两个隐藏条件限制：
- 只匹配当前视口（viewport）内已加载的内容。大文件（>10MB）或折叠区域里的词不会被纳入
- 严格区分大小写：如果文档里混用
Mode和mode，Alt+F3默认只选中小写的mode；需先打开查找面板（Ctrl+H），勾选Match Case才能控制行为 - 它不识别语义边界：比如
userMode中的mode会被连带选中——这不是 bug，是正则底层行为。避免方法是先用鼠标双击选中独立词，再按Alt+F3
用 Ctrl+Shift+L 拆行时，为什么光标跑到行尾或空行？
Ctrl+A → Ctrl+Shift+L 是最暴力也最容易失控的多游标生成方式。它的逻辑是“把每行末尾当作光标插入点”，所以：
- 如果某行末尾有空格或制表符，光标会落在空白符之后，输入时内容会挤在空格右边
- 空行也会生成一个游标，但位置在行首（不是行尾），此时输入会覆盖该行——常被误认为“没反应”
- 真正安全的做法是：先用
Ctrl+L逐行选中（光标停在行首），再按Ctrl+Shift+L，这样所有游标都对齐在行首，适合统一加前缀（如//）
鼠标拖拽多游标（Shift+鼠标右键）的实际限制
这个操作看起来自由，实则受限于 Sublime 的渲染机制：
- 仅在“普通编辑模式”下有效；进入命令面板（
Ctrl+Shift+P）、查找面板（Ctrl+H）或侧边栏时，Shift+鼠标右键会失效 - 拖拽方向必须是垂直或水平直线，斜向拖拽只会生成起点到终点的矩形块，而非多列游标
- 跨折叠代码块时，游标无法穿透折叠区域——它只作用于当前展开的文本行
- 更可靠的替代方案：用
Ctrl+Click（Windows/Linux）或Cmd+Click（macOS）在任意位置点击添加游标，支持非连续、跨折叠、跨文件（需提前激活对应标签页）
真正卡住多数人的不是快捷键记不住，而是没意识到 Sublime 的多游标永远基于“当前光标位置的上下文”做判断——它不猜你意图，只忠实执行规则。一旦光标落点偏差、大小写没对齐、或文件太大导致视口截断，结果就不可控。动手前花两秒确认光标在哪、当前是否开启 Match Case、目标词是否孤立，比反复 Escape 重来快得多。
