关不掉悬停提示是因为gitlens.showcurrentlineblame仅控制状态栏信息，真正控制鼠标悬停的是gitlens.hovers.enabled（必须设为false）和gitlens.codelens.enabled（设为false可停codelens文本），二者需同时禁用且必须用布尔值false而非字符串。
gitlens.showCurrentLineBlame 关不掉悬停提示？
关掉 gitlens.showCurrentLineBlame 只能停掉状态栏里的作者/时间信息，但鼠标移到代码行上依然会弹出 blame 提示——因为这个悬停是独立注册的 hover provider，和该配置无关。真正控制悬停的是 gitlens.codeLens.enabled 和 gitlens.hovers.enabled。
必须同时禁用两个 hover 开关
GitLens 的行内提示由两套机制叠加：一个是代码行上方的 CodeLens（如 “Last modified by…”），另一个是鼠标悬停时的 blame 信息框。两者需分别关闭：
-
gitlens.codeLens.enabled→ 设为false，停掉行首/行中所有 CodeLens 文本 -
gitlens.hovers.enabled→ 设为false，这才是真正关掉鼠标悬停弹窗的开关
只关其中一个，另一类提示仍会干扰编码。这两个字段在 VSCode 设置里搜不到 GUI 选项，必须手动写进 settings.json。
别被 “disable” 字符串坑了
某些 GitLens 版本（尤其是 v2025.10+）把布尔型配置误标为字符串类型，比如把 "gitlens.hovers.enabled": "disable" 写成字符串，VSCode 会静默忽略——它只认 true/false 布尔值。一旦写成 "false"（带引号）或 "disable"，配置就失效。
正确写法只有：
"gitlens.hovers.enabled": false, "gitlens.codeLens.enabled": false
保存后无需重启，但得把当前文件重新打开（或触发一次编辑器重绘），否则旧 hover provider 可能还在内存里挂着。
多扩展共存时怎么定位是谁在弹窗
如果你关了 GitLens 所有 hover 相关设置，悬停提示还在，大概率是其他 Git 扩展（比如 Git History、Git Graph）也在注册自己的 hover provider。VSCode 不提供 hover 来源追溯功能，只能靠排除法：
- 临时禁用所有 Git 类扩展，只留 GitLens，看提示是否消失
- 逐个启用，每启一个就试一次悬停
- 重点盯
git-history的gitHistory.hover.enabled和git-graph的git-graph.hoverEnabled
这类配置名没有统一规范，得点开每个插件的 settings.json 注释或 GitHub README 才能找到真实字段名。最麻烦的是，它们可能共享同一个 hover 区域，导致提示内容堆叠显示——这时候关一个，另一个照样弹。
