Sublime Text多光标编辑时新光标不会自动滚入视野，仅最新激活光标所在行会被被动滚动可见；需配合Ctrl+L、auto_center设置及手动对齐行号实现视觉同步。
Sublime Text 的多行编辑（即多光标）本身不改变滚动行为，所有滚动控制仍由视图（View）层级决定；所谓“多行编辑时自动滚动”，其实是光标移出可视区域后触发的被动跟随，不是独立功能。
多光标操作中怎么让新光标自动滚入视野
当你用 Ctrl+Click、Ctrl+D 或正则选中多处并生成多个光标时，Sublime 默认会在你按方向键或输入时，把「最新激活的光标」所在行拉进可视区域——但其他光标不会被主动带进来。这不是 bug，是设计：它优先保障当前操作焦点可见。
- 确保
"scroll_past_end"为true（默认），否则光标卡在文件末尾时无法继续下滚 - 禁用
"center_selection_on_scroll"（设为false），否则每次移动都会强制居中，打乱你已对齐的上下文位置 - 若某光标被挡在视口外，按
Ctrl+L选中该行 → 再按Home或End，会触发一次强制滚动使其可见 - 不要依赖
PageDown带动多光标滚动——它只按视口高度翻页，和光标位置无关
分屏下多光标编辑时两个视图怎么保持视觉对齐
同一文件开两个视图（用 New View into File）后，你在任一视图中加多光标，另一视图不会同步生成光标，但编辑会实时反映。想让两栏“看起来同步”，关键不是滚动联动，而是让光标落在相似逻辑位置：
- 必须启用
"auto_center"（设为true），这样每个视图里当前光标行都会居中显示 - 先在一个视图中用
Ctrl+D选中目标模式，记下其中某个光标所在行号（比如第 87 行） - 切换到另一视图，按
Ctrl+G输入87，再手动用Ctrl+D复现相同匹配 —— 这样两栏光标才真正“对齐” - 如果两视图字体大小或行高不同，
auto_center效果会错位，需统一设置"font_size"和"line_padding_top"/"line_padding_bottom"
为什么 Ctrl+鼠标滚轮缩放字体时会意外滚动内容
这不是滚动控制失效，而是事件冲突：Ctrl+滚轮 在 Sublime 中默认绑定为字体缩放，但如果鼠标驱动（如 Logitech G HUB）启用了「智能滚动」或「滚动方向翻转」，它可能把 Ctrl+wheel_up 误报为普通 wheel_up，导致编辑区被向上滚动而非缩放。
- 先检查鼠标驱动软件，关闭所有“超速滚动”“惯性滚动”“方向翻转”类选项
- 确认 Sublime 的
Default (YourPlatform).sublime-mousemap中没有错误覆盖"modifiers": ["ctrl"]的绑定 - 临时验证：在无插件纯净模式下（启动时加
--safe-mode参数）测试Ctrl+滚轮是否正常缩放 - 若仍异常，可手动重绑，在用户 mousemap 中明确写：
[{"button": "scroll_up", "modifiers": ["ctrl"], "command": "zoom_in"}, {"button": "scroll_down", "modifiers": ["ctrl"], "command": "zoom_out"}]
自定义 scroll_lines 绑定后多光标滚动变卡顿怎么办
当你在 Key Bindings 里绑定了 scroll_lines 替代原生 page_up/page_down 后，多光标场景下可能出现响应延迟——因为 scroll_lines 是逐行计算偏移，而多光标叠加时需为每个光标单独处理滚动边界，CPU 负担陡增。
- 避免用小数
amount（如-1.5），Sublime 内部会做浮点运算+插值，加剧卡顿 - 把
amount改为整数（如-10），并搭配"scroll_speed": 0.4控制动画节奏，比小步高频更稳 - 如果只是想“快速跳转”，直接用
Ctrl+G输入行号，比滚动更准更快，且完全绕过渲染压力 - 装了
SyncedScroll插件时，它的跨视图同步逻辑会和自定义scroll_lines冲突，建议禁用插件单独测试
真正难调的不是参数，而是预期：Sublime 的滚动永远服务于「当前焦点」，而不是「所有光标」。想靠滚动覆盖全部多光标位置，不如用 Ctrl+Shift+P → Find in Files 批量定位，再分批处理——这才是高效路径。
