ctrl+←/→在多光标下会合并光标而非逐个跳转，仅保留主光标并执行单词跳转；sublime底层不支持多光标单词跳转，因move命令为单光标语义且无批量移动api；替代方案包括esc退出后重建光标、home对齐缩进起点、ctrl+shift+l按结构特征对齐光标，或确保"drag_text": false以避免拖动干扰。
Ctrl+←/→ 在多光标下会合并光标，不是逐个跳转
多光标状态下按 Ctrl+←（Windows/Linux）或 Option+←（macOS），Sublime 不会分别移动每个光标，而是直接清空所有非主光标（即只保留最开始那个光标），然后对它执行单词跳转。这是默认行为，不是 bug。
常见错误现象：你刚用 Ctrl+D 选了 5 个 user_id，想把每个光标都往前跳一个词去改前缀，结果一按 Ctrl+←，只剩一个光标停在 user_id 开头——其他光标全没了。
- 想保留多光标又跳转？先按
Esc退出多光标状态，再用Ctrl+←跳到目标位置，然后重新加光标（比如Ctrl+Click或Ctrl+D） - 如果目标是统一调整多个光标的位置（比如全移到行首），用
Home更可靠；但注意：它跳的是“缩进起点”，不是绝对行首，连续按两次才能跳过缩进 -
Ctrl+Shift+←也不支持多光标——它只会扩展主光标的选区，其他光标照样消失
为什么多光标 + 单词跳转不兼容
Sublime 的单词跳转命令（move 命令带 by: "words"）设计上就是单光标语义。内核不维护“每个光标独立的词边界上下文”，所以无法判断第 3 个光标该停在 api_v2 还是 v2 前面。
这跟列选择（Alt+拖拽）或 Ctrl+Shift+L 的行为逻辑完全不同：后两者是“生成新光标”，而 Ctrl+← 是“移动当前光标”，二者底层调用的 API 完全隔离。
- 即使你手动在 Key Bindings 里给
Ctrl+←绑定{"command": "move", "args": {"by": "words", "forward": false, "extend": true}}，它依然只作用于主光标 - 插件也无法绕过这个限制——Sublime API 没暴露“批量 move 光标”的接口
- 如果你真需要“所有光标同步向左跳一个词”，唯一可行路径是：用正则查找定位每个光标前方的词边界，再批量插入新光标，成本远高于手动操作
替代方案：用列选择或 Home 配合多光标更可控
真正适合多光标场景的“位置对齐”操作，不是靠单词跳转，而是靠视觉锚点或结构特征：
- 要让所有光标移到每行变量名开头？先用
Ctrl+Shift+L拆出光标，再按Home（两次）跳过缩进，比猜单词边界稳得多 - 要对齐某列（比如等号、冒号、括号）？用
Ctrl+Shift+→扩展选区到目标列，再Ctrl+Shift+L拆，光标就落在同一列 - 想批量删掉某个前缀（如
old_）？双击选中第一个old_user_id，按Ctrl+D扩展，再按Ctrl+Shift+→选中old_部分，直接删——不用跳转
drag_text 为 true 时，Ctrl+Click 会拖文本而非加光标
这个设置会间接破坏你重建多光标的能力——你想用 Ctrl+Click 把光标加到另一行，结果鼠标一按就拖动了上一行已选中的文本，光标没加成，还污染了剪贴板。
必须确认用户设置里有这一行：
"drag_text": false
否则任何依赖鼠标添加光标的后续操作（包括想跳转后再点加光标）都会失效。改完需重启 Sublime 才生效，临时切输入法或重装插件都没用。
真正容易被忽略的是：这个设置一旦为 true，连 Ctrl+Shift+L 拆出来的光标，在你尝试用方向键微调时，也可能意外触发拖动——因为 Sublime 把“光标移动”和“文本拖动”共用了同一套底层事件判定逻辑。
