直接按ctrl+shift+p（win/linux）或cmd+shift+p（macos），输入git: toggle blame回车即可快速开启/关闭行级作者追溯，信息显示在编辑器左侧gutter，需文件已提交且工作区为git仓库根目录。
怎么用快捷键快速开启/关闭 Git Blame
直接按 Ctrl+Shift+P（Windows/Linux）或 Cmd+Shift+P（macOS），输入 Git: Toggle Blame 回车即可——这是 VSCode 原生 Git 扩展提供的命令，无需插件、不依赖 GitLens。
注意：不是 Git: Toggle Line Blame（旧名，已弃用），也不是 GitLens: Toggle Line Blame（那是插件命令，行为不同）。如果没反应，先确认左下角状态栏显示分支名（如 main），且当前文件在 git ls-files 输出中。
- 快捷键最稳，右键菜单易误点成“Blame Annotations”（只影响状态栏，不显示 gutter 注释）
- 光标必须落在已提交的代码行上，新建文件或未
git add的文件会显示Unknown author - 执行一次开启，再执行一次关闭；VSCode 不会自动记住上次状态
为什么 Blame 显示的作者不是这行代码的“原始作者”
git blame 找的是“最后一次修改该行内容”的提交，不是“第一次写出这行”的人。格式化、自动修复、rebase 合并、甚至整块粘贴，都会覆盖原始归属。
- 某行被 Prettier 重排过 → Blame 指向格式化那次提交，而非业务逻辑编写者
- 合并时用了
squash merge→ 原始提交被压平，Blame 只能追溯到 squash 提交的作者 - 用
git commit --amend修改了提交 → 原 author 信息可能丢失，尤其 name 字段为空时
想查原始实现？得结合 git log -p -L 往更早提交里翻，Blame 本身做不到。
GitLens 的 Show Line History 和原生 Blame 有什么区别
原生 Git: Toggle Blame 只返回最近一次修改；GitLens 的 Show Line History（快捷键 Alt+H L）则调用 git blame -L，列出所有影响该行的提交，含 diff 对比。
- 它对空行、纯注释、刚新增未提交的行不返回结果
- 若某次提交删了整段又重建，历史链会中断——
git blame -L无法跨删除重建追溯 - 需确保
gitlens.blame.lineEnabled和gitlens.historyExplorer.enabled都为true，否则右键菜单不出现该选项
别指望它补全“谁写了第一版”，它只是把 git blame -L 的命令封装得更易触发。
Blame 显示错行或跳转到错误提交怎么办
常见原因不是 VSCode 故障，而是底层 Git 状态和环境偏差导致的行号偏移。
- 本地有未暂存修改：Blame 会把当前编辑器里的脏内容“归因”给某个旧提交，实际那行根本没变过
- Windows + WSL 克隆仓库，但 VSCode 用 Windows 路径打开，且
core.autocrlf=true→ CRLF 换行被转换，行号对不上 - 启用了
blame.ignoreRevsFile但忽略提交里包含了该行的变更 → 后续修改被错误归到更早提交 - GitLens 插件与原生 Blame 冲突：禁用 GitLens 后测试，若恢复正常，说明是插件覆盖了行为
最可靠的验证方式：终端进仓库根目录，手动跑 git blame -L 42,42 -- src/file.js，看输出是否和 VSCode 一致——不一致就说明编辑器层有干扰。
