editor.hover.enabled关不掉git blame提示，因其悬停由gitlens等扩展独立实现；需禁用gitlens.showcurrentlineblame和gitlens.codelens.enabled，或排查git history等第三方扩展的hover设置。
为什么 editor.hover.enabled 关不掉 Git Blame 提示
因为 Git Blame 的悬停提示（比如 alice@abc123 2024-03-15）通常不是由 VSCode 原生 Hover 系统触发的，而是由扩展（如 GitLens 或内置 Git 功能）独立注册的。即使你把 editor.hover.enabled 设为 false，这些提示仍会弹出——它们压根不读这个开关。
GitLens 的行级 blame 提示必须手动关闭
如果你装了 GitLens，它的 blame 悬停是默认开启的，且和 editor.hover 完全解耦。要关掉它，得动两个关键设置：
-
gitlens.showCurrentLineBlame→ 设为false（这是状态栏和悬停显示作者/时间的核心开关） -
gitlens.codeLens.enabled→ 设为false（否则左侧行号旁还会显示“Last modified by…”这类代码镜头）
操作路径：Ctrl+, → 搜索关键词，逐个禁用；或直接编辑 settings.json 加入：
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
"gitlens.showCurrentLineBlame": false, "gitlens.codeLens.enabled": false
内置 Git blame 悬停怎么关
VSCode 内置的 Git blame（不依赖插件）只在你主动调用时才出现，比如右键 → “Git: Blame” 或按 Ctrl+Shift+P 输入 Git: Toggle Line Blame。它本身没有常驻悬停行为——如果你看到悬停就出 blame 信息，那一定是某个扩展干的。
- 检查已启用的 Git 相关扩展：如
Git History、Git Graph、Git Project Manager - 逐个禁用，观察悬停是否消失；常见“背锅者”是
Git History，它的配置项叫gitHistory.showHover，值必须是字符串"disable"，写成false会失效
Terminal 里的链接悬停是另一回事
终端中鼠标悬停显示可点击链接（如文件路径、URL），是由 terminal.integrated.showLinkHover 控制的，和代码编辑器中的 Git blame 无关。如果误关了这个，却以为关掉了 blame，会白忙活一场。确认你关的是编辑器区域，不是终端面板。
真正难搞的是多层叠加：GitLens + 内置 Git + 第三方 Git 扩展可能同时注册 hover provider，而 VSCode 不提供 hover 来源追溯功能——只能靠禁用+重启来定位。
