sublime text 无真正平滑滚动动画，仅支持命令驱动的轻微缓动（smooth_scroll）和触控板/滚动条拖拽的惯性滑行（animate_inert_panning），鼠标滚轮等行为由系统控制。
Sublime Text 原生不支持真正意义上的平滑滚动动画（即带缓动插值的连续帧滚动），所谓“开启平滑滚动”实际只有两种有效手段：启用惯性滑行或调整视觉反馈密度，不是 VS Code 那种 editor.smoothScrolling。
Sublime 的 smooth_scroll 是什么？
它是一个真实存在的用户配置项，但作用被严重高估。启用后仅让方向键、PageUp/PageDown、Ctrl+G 跳转等「命令驱动滚动」行为在视觉上略微“缓动”，并非帧动画——本质是多加了几帧中间位置计算，且依赖渲染线程空闲度。
-
"smooth_scroll": true必须手动写入 Preferences → Settings 的右侧用户配置中，JSON 格式要合法（逗号、括号、引号全英文） - 它对鼠标滚轮、触控板拖拽、滚动条拖拽完全无效——这些走的是底层视图位移路径，不经过该逻辑
- 低端显卡或开启大量插件时，
smooth_scroll可能降级为普通跳变，无任何报错提示 - 别和
scroll_speed混用：后者只缩放拖拽/滚轮的步长（比如每次滚 0.3 行），仍是瞬时跳变，不是动画
真正带“滑行动画感”的设置只有 animate_inert_panning
这是 Sublime 唯一一个会让视图产生物理惯性反馈的行为，仅作用于「按住滚动条拖拽」或「触控板快速滑动后松手」这两个场景，类似 macOS 的手感。
- 在用户设置中添加：
"animate_inert_panning": true，设为false则松手即停 - 它不影响鼠标滚轮、方向键、Ctrl+G 等任何其他滚动方式
- Windows/macOS/Linux 全平台生效，但依赖系统触控板驱动是否上报 velocity 信息；部分 Logitech 驱动会吃掉该事件，需关闭「Infinite scrolling」
- 值不能设为数字或字符串，只能是布尔值；设成
"true"（带引号）会导致解析失败，静默忽略
鼠标滚轮太生硬？先调系统，别碰 Sublime 配置
Sublime 不接管原始滚轮事件，所有“滚轮滚动快慢”问题，90% 出在操作系统层。强行在 Sublime 里调 scroll_speed 或改 mousemap 属于本末倒置。
- Windows：设置 → 设备 → 鼠标 → 「一次滚动的行数」，建议设为 1（细腻）或 5（快）
- macOS：系统设置 → 鼠标 → 「滚动速度」滑块直接拖，影响全局包括 Sublime
- Linux（GNOME）：设置 → 鼠标和触摸板 → 滚动速度；KDE 用户可用
xinput set-prop "Your Mouse" "libinput Scroll Method Enabled" 0 1 - 外接鼠标驱动（如 Logitech Options、Razer Synapse）常默认劫持 Ctrl+滚轮，关掉「全局快捷键」类选项
别信“光标平滑移动”能改善滚动体验
像 caret_style: "phase" 或 caret_extra_width 这类设置，只影响光标自身闪烁/尺寸，和视图滚动毫无关系。它们解决的是「跳转后找不到光标」的问题，不是「滚动过程割裂」。
-
"scroll_to_cursor": true是个常见误传——Sublime 根本没有这个配置项，写进去也无效 - Ctrl+P 搜索后光标偏出可视区，是 Sublime 的默认行为，靠
smooth_scroll无法修正，得靠插件（如 AutoScrollToCursor）或手动按Ctrl+L居中 - 如果追求连贯性，更实际的做法是：禁用光标闪烁（
"caret_blink": false），配合增大光标宽度，让跳转后的定位更快被眼睛捕获
真正容易被忽略的点是：Sublime 的滚动行为由三套独立机制并行控制——系统输入事件分发、编辑器命令执行、视图渲染调度。改一个配置没效果，大概率是其中某一层被外设驱动、显卡设置或第三方主题拦截了，而不是配置本身写错了。
