Sublime Text原生不支持光标移动加速，需通过快捷键组合、滚动配置和视觉优化模拟高效导航；核心是解决“找得到、跟得上、回得去”，而非追求动画效果。
Sublime Text 原生不支持“光标移动加速”——它没有类似 VS Code 的 editor.cursorSmoothCaretAnimation 或可调加速度的游标物理模型。所谓“加速”，实际是靠组合快捷键、合理配置滚动行为与视觉反馈来模拟高效导航感。
为什么方向键/鼠标滚轮感觉“不够快”？
这不是 Sublime 卡，而是它的设计哲学：所有光标跳转（Ctrl+G、Ctrl+P、方向键）都是帧同步瞬移，不插值、不缓动。好处是低延迟；坏处是长文件里反复按方向键或滚轮时，容易产生“手动拖拽”的疲惫感。
- 系统级滚轮设置被忽略：Sublime 的
scroll_speed只调节“滚动条拖拽”和“滚轮滚动”的**惯性衰减系数**，不改变单次滚轮触发的行数——那由操作系统决定 - 触控板用户更明显：macOS 默认“自然滚动” + Sublime
scroll_speed: 0.4配合才顺；纯鼠标用户若开 Logitech G HUB 的“超速滚动”，反而会覆盖 Sublime 的平滑逻辑 - Vintage 模式下
Ctrl+Shift+↑/↓直接失效——Vim 键绑定接管了全部方向行为，不是快捷键冲突，是模式切换导致命令未注册
真正提升长文件导航效率的三件事
别盯着“让光标飞起来”，要解决“找得到、跟得上、回得去”：
-
启用自动跟随光标：原生
scroll_to_cursor不生效，必须用轻量插件监听on_selection_modified事件，且务必加视口判断，否则大文件里疯狂滚动会卡顿：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}) -
调低
scroll_speed并同步系统设置：在用户设置中加"scroll_speed": 0.35，然后立刻去系统设置里把鼠标/触控板的“滚动速度”调到中高区间（Ubuntu 用xinput --set-prop；macOS 用终端改defaults write -g NSScrollAnimationEnabled -bool true） -
用跳转代替移动：
Ctrl+P（文件）、Ctrl+R（符号）、Ctrl+;（行号）、F4（上一个错误）比狂按方向键快十倍；配合Ctrl+Alt+-/Ctrl+Shift+-快速回溯跳转历史，这才是 Sublime 的导航主干道
光标样式与尺寸对“感知速度”的影响远超预期
人眼判断“光标是否跟手”，70% 依赖视觉确定性，而非动画流畅度。细竖线光标在高分屏或小字号下极易丢失，造成“我按了但没反应”的错觉。
-
"caret_style": "wide"或"solid"比默认"phase"更易定位；Retina 屏建议从"caret_extra_width": 3起试，普通屏1~2足够 - 关闭闪烁（
"caret_blink": false）能消除跳转后“等一次闪烁才确认位置”的心理延迟，尤其适合多显示器或高亮度环境 -
"caret_extra_top"和"caret_extra_bottom"各加1～2，让光标在行内略“拉长”，避免紧贴文字基线带来的视觉压迫感
最容易被忽略的是：Sublime 的“导航效率”不取决于你按了多少下方向键，而取决于你有没有让光标永远处于“一眼可见、一击即达、一步可退”的状态。配置只是辅助，习惯才是核心。
