Sublime Text 没有鼠标平滑滚动功能，smooth_scroll仅影响命令触发的视图位移（如Ctrl+G、PageDown），对鼠标滚轮完全无效；真正可调的是scroll_speed（控制滚轮步长）和animate_inert_panning（仅对滚动条/触控板松手惯性生效），二者需配合animation_enabled才能起效。
Sublime Text 没有鼠标平滑滚动——这个说法不是妥协，而是事实。它不处理原始滚轮事件，也不渲染光标运动轨迹，所有“滚得生硬”“滑不动”的抱怨，90% 出在系统层或配置误用。
为什么 smooth_scroll 对鼠标滚轮完全无效
smooth_scroll 只影响命令触发的视图位移：比如 Ctrl+G 跳转、PageDown 翻页、或插件调用 goto_line。它会让这些操作“分几步走”，但仍是离散帧，不是插值动画；且对鼠标滚轮、触控板滑动、滚动条拖拽全部不响应。
- 写了
"smooth_scroll": true却发现滚轮没变化？正常，它本来就不该管 - 项目级
.sublime-project里写了"smooth_scroll": false，会直接覆盖用户设置 -
"editor.smoothScrolling": true是 VS Code 的字段，Sublime 解析失败，静默忽略
真正能改“滚动手感”的两个配置项
scroll_speed 和 animate_inert_panning 是唯二有效参数，但作用完全不同，不能混为一谈：
-
scroll_speed：控制“每次滚轮或拖滚动条移动多少行”，默认1.0，建议设为0.35–0.5。值越小越细腻，但低于0.1会导致滚动条拖不动、响应迟钝 -
animate_inert_panning：仅对“按住滚动条拖拽后松手”或“触控板快速滑动后松手”生效，带来惯性滑行感。必须搭配"animation_enabled": true才起效，写成"true"（带引号）会解析失败 - 两者可共存，例如：
{"scroll_speed": 0.4,"animate_inert_panning": true,"animation_enabled": true}
鼠标滚轮太猛？先动系统设置，不是 Sublime
Sublime 不接管原始滚轮事件，它只接收系统发来的“滚动 N 行”指令。所谓“调平滑”，第一步永远是操作系统级调整：
- Windows：设置 → 设备 → 鼠标 → 「一次滚动的行数」，设为
1或2最稳妥 - macOS：系统设置 → 鼠标 → 「滚动速度」滑块拉到中间偏右；再终端执行
defaults write -g NSScrollAnimationEnabled -bool true - Linux（GNOME）：设置 → 鼠标和触摸板 → 滚动速度；若不够，装
imwheel，把 Button4/Button5 后数值从3改为4–6 - Logitech / Razer 用户：务必关闭驱动里的「超速滚动」「Infinite scrolling」，否则 Sublime 收不到原始 delta
别碰 sublime-mousemap 里的无修饰键绑定
网上有些教程教你在 Default (Windows).sublime-mousemap 里写：
{"button": "wheel_up", "command": "scroll_lines", "args": {"amount": 1}}这是高危操作：
- 它会干掉所有基础滚动：编辑区、侧边栏、控制台、查找面板全无法上下滚动
- 该绑定全局生效，无法限定作用域（比如只对编辑区起作用）
- 恢复成本高：需手动删文件、重启，并排查插件是否残留干扰
- 真要微调，只建议绑定带修饰键的行为，如
"modifiers": ["ctrl"]做缩放
最容易被忽略的点是：惯性滑行（animate_inert_panning）依赖系统触控板驱动是否上报 velocity 信息，部分 Logitech 驱动会吃掉该事件；而 scroll_speed 在高 DPI 或远程桌面环境下，实际滚动距离可能被系统二次放大——这些都不是 Sublime 自身能修正的边界问题。
