Minimap与垂直滚动条冲突的根源是渲染层叠顺序和占位逻辑不一致，需同时禁用overlay_scrollbar并调整minimap_enabled或配合minimap_scroll_to_cursor设置来解决。
Minimap 和垂直滚动条在右侧“打架”，不是 Bug，是渲染层叠顺序和占位逻辑没对齐。真正要动的不是 Minimap 本身，而是它和 overlay_scrollbar 的共存策略。
为什么滚动条被遮住或点不中？
根本原因不是 Minimap 太宽，而是 Sublime 默认启用 overlay_scrollbar——它把滚动条画成“浮层”，但位置计算时仍预留固定宽度。当 minimap_enabled 为 true 时，Minimap 容器和 overlay 滚动条共享同一竖直区域，鼠标事件优先捕获到 Minimap 区域，滚动条就“点不中”或“半透明盖住”。尤其在 macOS 或 Wayland 环境下更明显。
-
minimap_position设为"right"（默认）时，Minimap 容器始终占据最右边缘 -
overlay_scrollbar即使设为true，也并非真正“叠加”在 Minimap 上，而是渲染坐标重合，导致点击穿透失效 - 换主题（如 Material、Dracula）后问题加剧，是因为它们在
.sublime-theme中硬编码了minimap_control规则，覆盖了原生滚动条定位逻辑
怎么让滚动条重新可点、不被遮？
必须同时调整两个设置：禁用 overlay 滚动条 + 显式释放 Minimap 占位空间。只关 Minimap 不够，只关 overlay_scrollbar 也不行。
- 在用户设置（
Preferences → Settings右侧）中加这两行：{"minimap_enabled": false,"overlay_scrollbar": "disabled"} - 不要用
"overlay_scrollbar": false——Sublime 4+ 只识别"disabled"字符串值，false会被忽略 - 改完保存，新开窗口立即生效；已有窗口执行
toggle_minimap命令或重启一次，确保设置加载完整 - 验证是否生效：控制台输入
sublime.active_window().active_view().settings().get('minimap_enabled')应返回False，sublime.active_window().active_view().settings().get('overlay_scrollbar')应返回"disabled"
Minimap 开着但还想保滚动条可用？
可以，但得牺牲自动居中和高亮干扰。关键在于切断 Minimap 和视图滚动的耦合：
- 保持
minimap_enabled为true，但加这三项：{"minimap_scroll_to_cursor": false,"minimap_scroll_to_click": true,"overlay_scrollbar": "disabled"} -
minimap_scroll_to_cursor: false是重点——它阻止光标移动时 Minimap 强制重定位，避免和滚动条争夺视图重绘权 -
overlay_scrollbar: "disabled"强制回退到传统滚动条，有明确像素边界，不会和 Minimap 渲染层冲突 - 别碰
minimap_width：调小只会让缩略图糊成色块，不解决点击问题；真正影响交互的是minimap_scroll_to_cursor和overlay_scrollbar的组合
真正容易被忽略的是：Minimap 是否“可见”和滚动条是否“可用”是两套独立逻辑。前者由 minimap_enabled 控制，后者由 overlay_scrollbar + 主题渲染规则共同决定。哪怕 Minimap 看不见，只要 overlay_scrollbar 还开着，右侧那几像素就还在抢点击事件。
