Sublime多光标本质是快捷键实时叠加而非模式切换，核心难点在于选区精准性、匹配逻辑与默认设置的协同；Ctrl+D严格字面匹配且依赖初始选区完整性，列选受字体/换行符影响，批量操作需前置清理空格、BOM及统一编码。
Sublime 的多光标不是“开启一个模式”，而是靠快捷键实时叠加光标点——按错一个键（比如 Esc、方向键、Ctrl+X），所有光标立刻消失。真正卡住人的，从来不是快捷键记不住，而是选区没建对、光标没落准、匹配逻辑被默认设置悄悄绕过。
Ctrl+D 为什么总选不全变量名
它不是全文搜索，而是从当前选区出发，严格匹配字面完全一致的字符串。双击 user_id 没选干净（带了空格、引号或点号），后续就只找 user；光标停在中间再按 Ctrl+D，会漏掉开头/结尾的同名实例。
- 双击变量名后，肉眼确认高亮区域完整包裹
user_id，前后无空格、引号、.或括号 - 检查大小写敏感：按
Ctrl+Alt+R（Windows/Linux）或Cmd+Alt+R（macOS）切换 - 想跳过某处（如字符串里的同名内容）：先按
Ctrl+K（松开），再按Ctrl+D - 误加太多光标？按
Ctrl+U撤销上一次光标扩展（不是撤销输入内容）
Ctrl+Shift+L 拆不出多个光标
这个操作只认「选区里有没有换行符」，不看你心里想选几行。鼠标拖选时最后一行末尾漏掉 \n，它就当单行处理；纯空行会被忽略；如果装了 Emmet 或其他插件，还可能劫持快捷键绑定。
- 安全做法：用
Ctrl+L（Windows/Linux）或Cmd+L（macOS）逐行点击目标行，再统一按Ctrl+Shift+L - 只出一个光标？说明选区没跨行——检查是否漏掉了最后一行的换行符
- 光标落在缩进空格后？按
Home把所有光标拉到各自行首（含缩进），再按一次Home跳过缩进到真正行首 - 去
Preferences > Key Bindings搜索split_selection_into_lines，确认绑定未被覆盖
列选择（Alt+拖拽）输完内容错位或没反应
这不是多光标，是矩形框选，和字体、行长度、输入法强相关。它不自动对齐，也不智能避让空行——某行太短，光标就停在行尾；混用中英文或非等宽字体，视觉上就歪了。
- 必须按住
Alt+Shift（Windows/Linux）或Option+Shift（macOS）再拖动，单独按Alt无效 - 某行该列是空格或换行符？光标自动跳到行尾——这是正常行为，不是 bug
- 视觉错位大概率因字体非等宽；换成
Consolas或Fira Code立刻稳定 - 列选后不能继续用
Ctrl+D；必须先按Esc退出列选状态 - Mac 用户注意：
Cmd+Shift+L常被搜狗/微软拼音劫持，临时切英文输入法再试
批量加前缀/后缀老是插错位置
加前缀不是按 Home 就完事——Sublime 的 Home 默认跳到第一个非空字符，不是物理行首；加后缀也不是按 End 就稳——它会停在行尾空白处，而非真正文本末尾。
- 加前缀（如
console.log(）：选中目标行 →Ctrl+Shift+L→ 按Ctrl+Shift+P输入Move to Beginning of Line（内置命令，无需插件）→ 输入 - 加后缀（如
;）：拆出多光标后，按End（Windows/Linux）或Cmd+→（macOS）→ 若某行结尾有空格，End会卡住；此时先运行Ctrl+Shift+P→Trim Trailing White Space - 正则替换加行首内容？点亮右下角
.*按钮再输^，否则^当普通字符处理 - 文件带 BOM（如 UTF-8-BOM）时，
^可能匹配不到首行开头；File → Save with Encoding → UTF-8最稳
最常被忽略的复杂点：没有万能方案。变量重命名用 Ctrl+D，参数对齐用列选，加固定前缀用 Ctrl+Shift+L + Move to Beginning of Line，而清理空格、统一换行符、删 BOM 这些前置动作，往往比编辑本身更决定成败。
