Sublime鼠标“不灵敏”主因是行为误配：drag_text默认true导致Ctrl+Click被识别为拖动而非多光标；需设为false并重启；输入法须英文；macOS注意Cmd+Space切输入法后焦点延迟；Ctrl+Shift+L按行末切光标，缩进/空格/空行致错位；滚轮卡顿源于系统设置而非scroll_speed；光标不居中因原生无跟随逻辑，需插件监听selection_modified并判断visible_region。
Sublime 里鼠标光标“不灵敏”，90% 不是响应慢，而是你没触发它该响应的行为——它根本没收到你的意图。
为什么鼠标点击不跳转、不加光标、不选中？
Sublime 默认把 Ctrl/Cmd + 鼠标左键当作「拖动文本」操作，不是「添加光标」。哪怕你松开了 Ctrl 再点，只要 drag_text 还开着，它就优先尝试拖拽，尤其在已有选区时，点击直接清空或移动文本，看起来像“没反应”。
- 检查用户设置里是否含
"drag_text": true（默认值）——必须手动改成false - 改完后重启 Sublime，别只 Reload Window；否则旧行为缓存仍在
- 点击前确认输入法是英文状态：中文输入法（尤其搜狗、百度）会劫持 Ctrl+Click，表现为点击无光标、甚至弹出候选框
- macOS 用户额外注意：系统快捷键
Cmd+Space切输入法会导致焦点延迟，刚切回来那一下点击大概率失效
Ctrl+Shift+L 多光标后光标乱飞？
Ctrl+Shift+L 不是对齐命令，它是按换行符暴力切选区，光标落点严格遵循「每行最后一个非空白字符之后」。缩进不齐、末尾有空格、某行为空，都会导致光标不在同一列，看起来像“跳来跳去”。
- 安全做法：先用鼠标从第一行行首拖到最后一行行尾（确保覆盖所有
\n），再按Ctrl+Shift+L - 想统一到行首？拆完立刻按
Home（所有光标同步跳至各行缩进起点），再按一次Home跳过缩进 - 想加前缀（如
//）？别用这个命令，改用列选择：Shift+Alt（Win/Linux）或Shift+Cmd（Mac）垂直拖动 - 空行或全空格行会导致光标落在奇怪位置——提前用
Ctrl+Shift+P→Remove Empty Lines清理
滚轮滚动卡顿、跳行、不跟手？
Sublime 不处理原始滚轮事件，它只接收系统发来的“滚动 N 行”指令。scroll_speed 调的是视觉步长密度，不是速度本身。滚轮“不灵敏”，大概率是系统层配置错位。
- Windows：进「设置 → 设备 → 鼠标 → 滚动」，把「一次滚动的行数」设为
1（细腻）或3（平衡）；关掉 Logitech G HUB 或 Razer Synapse 的「超速滚动」 - macOS：终端执行
defaults write -g NSScrollAnimationEnabled -bool true，再调系统「滚动速度」滑块到中高区间 - Linux：用
imwheel改Button4/Button5后数值，别依赖scroll_speed单独调 -
scroll_speed推荐值0.35～0.45；低于0.2会导致滚动条拖拽明显卡顿
光标不随滚动条自动居中？
Sublime 原生 scroll_to_cursor 命令在大文件里默认不触发，也不会监听光标移动。所谓“不跟手”，其实是编辑器压根没做任何跟随动作。
- 必须靠插件监听
on_selection_modified事件，且加视口判断，否则一开大文件就卡死 - 轻量实现示例（放入插件 Python 文件）：
def on_selection_modified(self):
sel = self.view.sel()
if not sel: return
cursor_pos = sel[0].b
if not self.view.visible_region().contains(cursor_pos):
self.view.run_command("scroll_to_cursor", {"show_at_center": False})
- 别用
show_at_center设为True——它强制居中会打断阅读节奏，False才是自然跟随 - 该逻辑在 10MB+ 文件里高频触发易卡顿，务必加
visible_region().contains()判断
最常被忽略的一点：所有这些行为都依赖焦点准确落入编辑区。如果右下角状态栏没显示当前文件编码（如 UTF-8）、或左下角没路径、或侧边栏是空的，说明 Sublime 还没真正加载上下文——此时任何鼠标交互都可能降级为标签页级操作，而不是编辑器本体响应。
