ctrl+u仅撤销最近一次多光标添加操作，按添加时间逆序回退，不撤销编辑；esc则彻底清空辅助光标、保留主光标；ctrl+z只撤销编辑动作，不处理光标状态。
Ctrl+U 是撤销多光标添加动作的唯一命令
Sublime 的多光标没有“撤销选中”这个概念，Ctrl+U（Windows/Linux）或 ⌘+U（macOS）干的是另一件事：倒退最近一次光标添加操作。它不碰你输入的字符、不撤替换内容、也不影响 Ctrl+Z 的编辑撤销栈。比如你连按 5 次 Ctrl+D 选了 5 处，第 4 处是误匹配，按一次 Ctrl+U 就回到 4 个光标，再按一次回到 3 个——严格按添加时间逆序，和位置无关。
常见错误现象：Ctrl+U 按了没反应。这大概率是因为用户设置里还开着 "drag_text": true，导致光标添加链路被拦截。必须手动关掉："drag_text": false，否则 Ctrl+U 始终无法感知到光标是怎么加进来的。
Esc 是比 Ctrl+U 更底层的重置操作
当你发现光标“只剩一个”“粘贴错位”“方向键一按就崩”，别再试 Ctrl+U 或 Ctrl+Z，直接按 Esc。它不走历史栈、不依赖焦点、不触发任何副作用，只做一件事：清空所有辅助光标，留下主光标（即最后操作的那个），且完全不影响已输入内容。
容易踩的坑：
- 误以为鼠标单击能替代
Esc——点偏可能展开折叠、选中行号，甚至拖动文本 - 在远程桌面或某些键盘布局下，
Alt+Tab等系统热键会干扰Alt+拖动列选，此时Esc依然稳如磐石 - 刚切回 Sublime 窗口、刚粘贴完、甚至鼠标点偏触发了代码折叠，
Esc都立刻生效
为什么 Ctrl+Z 救不了多光标失误
Ctrl+Z 只撤销编辑动作：删了哪几行、替换了什么文本、粘贴了什么内容。它完全不管光标怎么来的，也不保存光标添加历史。狂按 Ctrl+Z 想撤掉第 5 个误选的 user_id，结果把刚写的函数体也回退了——那不是撤销错，是用错了命令。
更麻烦的是，一旦你执行过编辑（比如输了个字母、删了个空格），再按 Ctrl+U 就会先撤销那个编辑，而不是光标动作；多按几次才能回到全选状态。所以容错的关键不是“补救”，而是“提前阻断”：
- 双击变量名时务必确认高亮区域干净：不含前后空格、引号、句点
- 混用
Ctrl+D和Ctrl+Shift+L时，节奏要慢——中间夹一次Ctrl+K（跳过）不会进Ctrl+U栈，但会导致撤错步 - 用
Find All前先检查正则是否勾选了.*（正则模式）和Aa（大小写敏感），否则匹配失败，根本不出光标
多光标为什么一碰就消失？这不是 bug，是设计
Sublime 的多光标是临时叠加，不是稳定模式。任意方向键、Backspace、Tab、Alt+Tab 切出再切回、甚至鼠标滚轮滚动，都可能触发自动合并或静默丢弃。表面看光标还在，实际只剩主光标卡在某处，其余已坍缩。
最典型的误操作是：按 ← 后以为光标还在多行，结果再输内容只出现在一行；或者粘贴时内容错位、漏行。这时候别挣扎，Esc 是唯一可靠落地操作。记住：只要做过移动、输入、切换等动作，就该默认光标已不可信。
