VSCode缩略图显隐仅通过设置"editor.minimap.enabled"控制，无快捷键；滚动条无原生快捷键，定位依赖鼠标或光标位置；二者交互分离但视觉共用区域，渲染逻辑独立导致可能错位。
缩略图（minimap）显隐不靠快捷键，靠设置开关
VSCode 没有默认绑定任何快捷键来控制缩略图（minimap）的显示/隐藏——它不是像侧边栏那样用 Ctrl+B 切换的临时 UI 元素，而是编辑器视图的一部分，受配置项直接控制。
常见错误现象：搜“minimap 快捷键”却找不到响应，或误以为 Ctrl+Shift+P 里能搜到 toggle minimap 命令，其实没有这个内置命令。
- 开启/关闭缩略图唯一可靠方式是改设置：
"editor.minimap.enabled": true或false - 可在用户 settings.json 中手动添加，也可在设置界面搜索 “minimap” 后勾选/取消 “Editor › Minimap: Enabled”
- 设为
false后，缩略图区域彻底消失，编辑器宽度自动扩展，不会残留空白条 - 该设置对所有工作区生效；若某项目想单独关闭，需在该项目
.vscode/settings.json中覆盖
滚动条定位依赖鼠标拖动，无原生快捷键支持
VSCode 编辑器右侧的垂直滚动条本身不响应键盘快捷键——你无法用 Ctrl+Home 跳到顶部，也不能用方向键精准滚动几行。它的定位逻辑完全由鼠标或触控板驱动。
容易踩的坑：以为存在类似 Sublime 或 Vim 的 g g / G 行跳转快捷键作用于滚动条，实际那是光标移动命令，和滚动条视觉位置无关。
-
Ctrl+Home/Ctrl+End移动光标到首/尾行，但滚动条不一定同步居中（尤其长文件中） -
Ctrl+U（向上翻页）、Ctrl+D（向下翻页）滚动视图，但属于“页面级”位移，非像素级精确定位 - 真正影响滚动条视觉锚点的是光标位置 + 编辑器可见区域高度；比如执行
editor.action.gotoLine（Ctrl+G）后，光标所在行会尽量居中显示，滚动条随之调整 - 若需快速回到上次编辑位置，用
Ctrl+Alt+Left（返回）比依赖滚动条更可靠
缩略图点击与滚动条拖动共用同一交互区域，但行为互斥
缩略图区域（右侧窄条）和主滚动条共享纵向空间，但它们的交互逻辑是分离的：点击缩略图任意位置会瞬间跳转光标到对应行，而拖动主滚动条则平滑滚动视图——两者不会互相干扰，但视觉上容易误判操作目标。
为什么有时点了缩略图没反应？不是功能失效，而是当前编辑器处于只读状态（如 diff 视图、输出面板），或文件过大导致缩略图渲染未就绪。
- 缩略图点击触发的是
editor.action.goToLocation类命令，依赖文件可编辑且已解析 - 主滚动条拖动是底层渲染层行为，不触发任何命令，也不写入 undo 栈
- 若同时启用了
"editor.minimap.showSlider": "always"，缩略图右侧会额外显示一个细长 slider，此时拖它等效于拖主滚动条，但精度更低 - 缩略图默认宽度为 12px；调大它（如设
"editor.minimap.width": "16px"）能提升点击容错率，但会略微压缩编辑区宽度
缩略图与滚动条的视觉一致性靠 editor.lineHeight 和 font-size 联动
缩略图线条密度和主编辑区行高不匹配时，会出现“滚动错位感”：拖动滚动条到底部，缩略图还剩一截没走完；或点击缩略图底部，光标却停在倒数第三行——这不是 bug，而是缩略图按字符渲染，而滚动条按像素计算。
根本原因在于缩略图高度 = 编辑器总行数 × 固定缩放因子，而滚动条位置映射依赖 editor.lineHeight 和字体实际渲染尺寸。
- 确保
"editor.lineHeight"是整数（如24），避免小数导致缩放取整偏差 - 禁用
"editor.fontLigatures"可减少连字对行高计算的干扰 - 若用等宽字体（如 Fira Code），优先选无连字版本，缩略图匹配度更高
- 修改
"editor.fontSize"后，务必重启编辑器或重载窗口（Ctrl+R），否则缩略图缓存可能不同步
